RFR (M) #5 CR 8003985: Support @Contended annotation

[Staffan Larsen]

This change seems to have broken deadlock detection in SA. Here is the exception that I get:

java.lang.RuntimeException: should not reach here
        at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327)

I haven't yet dug into the details. To reproduce, start any Java program, then run:

> sudo build/linux/linux_amd64_compiler2/jvmg/hotspot -cp build/linux/linux_amd64_compiler2/generated/sa-jdi.jar sun.jvm.hotspot.tools.JStack <pid of the program>

Using java runtime at: /home/staffan/java/8latest/jre
Attaching to process ID 28487, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.0-b15-internal-jvmg
Deadlock Detection:

java.lang.RuntimeException: should not reach here
        at sun.jvm.hotspot.oops.InstanceKlass.getFieldOffset(InstanceKlass.java:327)
        at sun.jvm.hotspot.oops.Field.<init>(Field.java:47)
        at sun.jvm.hotspot.oops.OopField.<init>(OopField.java:42)
        at sun.jvm.hotspot.oops.InstanceKlass.newField(InstanceKlass.java:915)
        at sun.jvm.hotspot.oops.InstanceKlass.findLocalField(InstanceKlass.java:628)
        at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:665)
        at sun.jvm.hotspot.oops.InstanceKlass.findField(InstanceKlass.java:689)
        at sun.jvm.hotspot.oops.OopUtilities.initThreadFields(OopUtilities.java:220)
        at sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:292)
        at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:385)
        at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82)
        at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
        at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
        at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
Can't print deadlocks:should not reach here


On 12 jan 2013, at 01:02, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:

> On 12/1/13 12:47 AM, Aleksey Shipilev wrote:
>> On 01/12/2013 03:40 AM, Vladimir Kozlov wrote:
>>> On 1/11/13 3:11 PM, Aleksey Shipilev wrote:
>>>> On 01/12/2013 02:10 AM, Vladimir Kozlov wrote:
>>>>> I mentioned this because for previous your changes "8004330: Add missing
>>>>> Unsafe entry points" I had to do it for you. You should make life of
>>>>> your sponsor better and not worse, we have a lot of other things to do.
>>>> OK, sounds fair. I wish you had this explanation in 8004330 timeframe. I
>>>> was under the false impression this is how we do the coordinated
>>>> HotSpot-JDK change.
>>> We (VM group) can push jdk changes again using hotspot-main/jdk repo as
>>> with 8004330 to synchronize push.
>> Ok, that was my impression as well.
> 
> Aleksey, If I understand this correctly you don't need a separate sponsor for the jdk changes (you asked for a sponsor in the jdk webrev).
> 
> Vladimir, are you suggesting that I push directly to hotspot-main? - all of it or just the jdk stuff?
> /Jesper
> 
>> 
>>> I just want a separate webrev for lib changes to let lib guys know what
>>> is coming to them.
>> Ok.
>> 
>>> Also VM push process (JPRT) does not do automatic push into jdk code
>>> together with VM changes - it is 2 different jobs. So we have to
>>> separate Hotspot and JDK changes.
>> :(
>> 
>>>>    http://cr.openjdk.java.net/~shade/8003985/webrev.vm.02/
>>> This looks better. Please, fix copyright year in Contended.java
>> Ah, I submitted the fixed year for JDK reviews. Fixed in VM webrev as
>> well now.
>> 
>> -Aleksey.
>