[concurrency-interest] synchronized constructors

Vitaly Davidovich 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;
>    someMethod();
>    m_field2 = 10;
> }
> public void someMethod()
> {
>     System.out.println(m_field2);
> }
> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Consulting Member of Technical Staff |
> 602.333.9091
> 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 [2] 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
> amortized.
> _______________________________________________
> 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111216/393f8182/attachment.html>

More information about the Concurrency-interest mailing list