RFR #2 (S) CR 8015270: @Contended: fix multiple issues in the layout code

[Daniel D. Daugherty]

On 5/27/13 11:53 AM, Aleksey Shipilev wrote:
> On 05/27/2013 09:24 PM, Daniel D. Daugherty wrote:
>> On 5/25/13 1:35 AM, Aleksey Shipilev wrote:
>>> Here's the merged changeset:
>>>     http://cr.openjdk.java.net/~shade/8015270/webrev.01/
>> Thumbs up!
> Thanks for the review!

No problem. I forgot to say that the unified review webrev didn't
appear to be tangled at all (to me).


>
>> hotspot/test/runtime/contended/HasNonStatic.java
>> hotspot/test/runtime/contended/OopMaps.java
>>      It would be good to update JDK-8015270 with information about
>>      what happens when these tests are run on a VM/JDK that does
>>      not have the fix. That will help with the bug fix verification
>>      process.
> I can do that. Is there an example of this practice somewhere in our
> code? Random sampling in hotspot/test yield no result. I'd like to see
> some uniform way we record this info in the regression tests -- will the
> Javadoc on test class suffice?

Sorry, I wasn't clear. I didn't mean to update the tests with the sample
failing output. I always like to put that stuff in the bug report.

Something like what I put in 7191322:

<begin sample>
Here is what a failing run with JDK7-B147 looks like:

#section:shell
----------messages:(3/183)----------
command: shell VerifyLocalVariableTableOnRetransformTest.sh []
reason: User specified action: run shell 
VerifyLocalVariableTableOnRetransformTest.sh
elapsed time (seconds): 3.869
----------System.out:(54/3613)*----------
InstrumentationHandoff JPLIS agent initialized
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

Reading test class from 
C:\\work\\shared\\bug_hunt\\jdk8\\exp_7064927_test\\sdk-jli.windows-i586\\JTwork\\classes\\java\\lang\\instrument\\DummyClassWithLVT.class
Read 1448 bytes.
Debugging message: Added transformer 
VerifyLocalVariableTableOnRetransformTest$MyObserver with 
canRetransform=true
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'DummyClassWithLVT' of 1448 bytes.
Info: DummyClassWithLVT lengths match.
Info: verified 'DummyClassWithLVT.class' matches 'classfileBuffer'.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'DummyClassWithLVT' of 1332 bytes.
Warning: DummyClassWithLVT lengths do not match.
Debugging message: tearDown beginning
Exception in thread "main" 
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/lang/Throwable$WrappedPrintStream' of 699 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/lang/Throwable$PrintStreamOrWriter' of 492 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/util/IdentityHashMap' of 9031 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/util/IdentityHashMap$KeySet' of 1793 bytes.
ATestCaseScaffold$TestCaseScaffoldException: DummyClassWithLVT did not 
match .class file
         at ATestCaseScaffold.fail(ATestCaseScaffold.java:116)
         at ATestCaseScaffold.assertTrue(ATestCaseScaffold.java:129)
         at 
VerifyLocalVariableTableOnRetransformTest.verifyClassFileBuffer(VerifyLocalVariableTableOnRetransformTest.java:123)
         at 
VerifyLocalVariableTableOnRetransformTest.doRunTest(VerifyLocalVariableTableOnRetransformTest.java:72)
         at ATestCaseScaffold.runTest(ATestCaseScaffold.java:60)
         at 
VerifyLocalVariableTableOnRetransformTest.main(VerifyLocalVariableTableOnRetransformTest.java:66)
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/lang/Shutdown' of 2956 bytes.
VerifyLocalVariableTableOnRetransformTest$MyObserver.transform() sees 
'java/lang/Shutdown$Lock' of 377 bytes.
ATestCaseScaffold$TestCaseScaffoldException: DummyClassWithLVT did not 
match .class file
FAIL: found 'did not match .class file' in the test output
INFO: 'javap -v' comparison between the .class files:
1,3c1,3
< Classfile 
/C:/work/shared/bug_hunt/jdk8/exp_7064927_test/sdk-jli.windows-i586/JTwork/classes/java/lang/instrument/DummyClassWithLVT.class
<   Last modified Aug 13, 2012; size 1448 bytes
<   MD5 checksum add938cbf65c704016583270092d8258
---
 > Classfile 
/C:/work/shared/bug_hunt/jdk8/exp_7064927_test/sdk-jli.windows-i586/JTwork/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest/DummyClassWithLVT.class
 >   Last modified Aug 13, 2012; size 1332 bytes
 >   MD5 checksum 65f4b7ecfaf38db537034ecd5723e85a
116,118d115
<       LocalVariableTable:
<         Start  Length  Slot  Name   Signature
<                0       5     0  this   LDummyClassWithLVT;
239,249d235
<       LocalVariableTable:
<         Start  Length  Slot  Name   Signature
<                0     236     0  args   [Ljava/lang/String;
<                2     234     1     b   Z
<                5     231     2    by   B
<                8     228     3     c   C
<               13     223     4     d   D
<               17     219     6     f   F
<               21     215     7     i   I
<               26     210     8     l   J
<               30     206    10     s   S
----------System.err:(0/0)----------
result: Failed. Execution failed: exit code 1


test result: Failed. Execution failed: exit code 1

<end sample>

The sample gives the VM/SQE engineer something to look for when they are
trying reproduce the original failure before they try to verify the fix.



>
>
>> JBS/administrivia issues:
>>
>> I bumped JDK-8015270 to P2 since JDK-8014886 is a P2.
> Oh, I think JDK-8014886 is P3, because the likelihood is low, and there
> is the workaround with either emulating @C on fields with class-level
> @C, or some other trick. I have not changed the priority for the closed
> issue, because did not thought it is relevant anymore. Please consider
> setting the priority back; I can do that along the change below:

I think you should be the one to lower the priority of _both_ bugs
with the explanation that you have given above.

The reason that this is important: There are some tools that look
specifically for bugs of a higher priority closed as dups of a
new bug with a lower priority. In the past some folks have used
that a covert means of lowering the priority of an issue in order
to get the issue off some list or another.

>
>> I believe the correct 'duplicate state' is:
>>
>>      JDK-8015270 duplicates JDK-8014886
>>      JDK-8015270 duplicates JDK-8014964
>>
>> since JDK-8015270 is the bug that is going to be used to get
>> the work done.
> Hmmm... I think you are right. Do you want me to relink these appropriately?

Yes, please.

Dan