[concurrency-interest] synchronized constructors

Nathan Reynolds nathan.reynolds at oracle.com
Fri Dec 16 11:31:48 EST 2011


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 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/59fd79db/attachment.html>


More information about the Concurrency-interest mailing list