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

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Nov 30 09:17:15 EST 2012


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.
> 
> 



More information about the Concurrency-interest mailing list