[concurrency-interest] synchronized constructors
vitalyd at gmail.com
Fri Dec 16 11:39:17 EST 2011
hotspot also does zeroing on demand. There was an email to one of the
other openjdk groups recently where a group built a prototype that mixed
block zeroing with on demand and found some improvement.
On Dec 16, 2011 11:33 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
> I am not sure about HotSpot, but JRockit doesn't zero a piece of memory
> until allocation time. The JRockit team found that zeroing memory at the
> time of allocation takes advantage of caching. Zeroing memory in GC causes
> the memory to be loaded into cache, evicted and reloaded at allocation
> time. Zeroing memory at allocation causes the memory to loaded into cache
> while being zeroed and then get an extra cache hit.
> JRockit does its best to avoid writing zeros to a memory location that
> will be overwritten with an initialized value. JRockit checks for the
> "this" reference escaping the constructor and other such problems. For
> example, in this code it will zero m_field2 but probably not m_field1. Why
> waste cycles and memory bandwidth zeroing m_field1 when it will be
> overwritten a few instructions later?
> private final int m_field1, m_field2;
> public MyObject()
> m_field1 = 5;
> m_field2 = 10;
> public void someMethod()
> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Consulting Member of Technical Staff |
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 12/16/2011 3:00 AM, Ruslan Cheremin wrote:
> so other threads may observe blank/partial state through `foo` reference. This reordering is
> allowed even if `Foo()` is synchronized.
> It's a very good explanation. Only to note -- if constructor is
> synchronized, as all other accessors, "partial" state can't be seen.
> But, sure, blank state -- can be.
> JMM does guarantee that  cannot be reordered before [B], otherwise
> other threads can observe garbage state. Let's call this the "blank"
> guarantee. It's also a mystery to me why whole-birth guarantee can be
> fundamentally more expensive than blank guarantee.
> As far, as I understand, blank guarantee is cheeper since it can be
> implemented in batch. AFAIK, it is GC who blanking reclaimed memory,
> so it can be done megabytes at once, and publishing reclaimed and
> zeroed memory also can be done at one shot. So, the cost is greatly
> amortized. But store-store barrier at the end of constructor, which
> seems to be required for your whole-birth guarantee can't be
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest