[concurrency-interest] @Contended (JEP-142)

Vitaly Davidovich vitalyd at gmail.com
Fri Nov 30 09:32:11 EST 2012


Why is header reported as 12 bytes? Should that not be two words (16 bytes
on x64)?

Yeah, the state I'd like us to be in is for heap analysis tools working
offline (I.e. against an hprof file) to have enough info to be able to
indicate to the user that the object size has padding applied.  The
existing 8 byte alignment is well understood/realized so people doing size
estimates in their head take it into account.  But 128 byte padding per
field may cause some confusion :).

Sent from my phone
On Nov 30, 2012 9:17 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Oh yes, but the same argument applies for "just" the gaps in field
> layout due to field alignment.
>
> This is a very simple proof-of-concept experiment, take the regression
> test from the @Contended patch:
>
>     // int1 is padded
>     public static class Test2 {
>         @Contended               private int int1;
>                                  private int int2;
>     }
>
> ...and run it with
>  https://github.com/shipilev/java-field-layout
>
> ...it will show you:
>
> $
>
> ~/trunks/jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
> -javaagent:target/field-layout.jar -cp
>
> target/field-layout.jar:/home/shade/trunks/jdk8/hotspot/test/runtime/8003985/
> net.openjdk.tools.fieldlayout.MainAnalyzer Test8003985\$Test2
>
> Test8003985.Test2
>    (header 12 bytes)
>   12   4             int Test2.int2
>    (gap 128 bytes)
>  144   4             int Test2.int1
> Instrumentation reports 280 bytes per instance
>
> ...the correct layout via Unsafe, and the exact object size, aligned to
> word size. So that info is available in VM. jhat/MAT, however, will show
> this object to retain only 24 bytes. AFAIK, this is just the glitch in
> Hotspot's HPROF dump code, which we can fix.
>
> -Aleksey.
>
> On 11/30/2012 05:48 PM, Vitaly Davidovich wrote:
> > Right,  but I meant that the tool will report proper size but developer
> > looking at that number may not immediately understand why the reported
> > size is larger than expected if padding is applied.  If the tool can
> > know that @Contended is present, it can indicate that to the developer.
> > I'm not familiar with the heap dump file format so don't know if there
> > will be enough info for the tool there.  I don't think instrumentation
> > applies here as the tool is interpreting a dump file and not profiling a
> > live application?
> >
> > Sent from my phone
> >
> > On Nov 30, 2012 8:41 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com
> > <mailto:aleksey.shipilev at oracle.com>> wrote:
> >
> >     On 11/30/2012 05:36 PM, Vitaly Davidovich wrote:
> >     > What's the plan for making this info available in heap dumps (taken
> >     > using jmap)? I'd imagine tools like Eclipse MAT may want to
> indicate
> >     > that a given instance of a class has padding applied.  Otherwise,
> the
> >     > object size reported won't match expectation (without knowing that
> >     > padding was applied).
> >
> >     Can't speak for other implementations, but HotSpot would report the
> >     proper sizes/offset via Instrumentation.objectSize and
> >     Unsafe.*fieldOffset. As long as tooling is not doing dumb
> >     "sum(fieldTypeCount*fieldSizeAsMandatedByJLS)", it should pick up the
> >     proper sizes.
> >
> >     -Aleksey.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121130/ff108fbf/attachment.html>


More information about the Concurrency-interest mailing list