RFR 8u backport: 8077608: [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode

[David Holmes]

Hi Stuart,

On 1/06/2017 11:26 PM, Stuart Monteith wrote:
> Hello,
>     I tested this on x86 and aarch64. Muneer's bug is an accurate
> description of the failing tests. I'm not sure what you mean by
> "8180904 has to be fixed before this backport", as the backport is the
> fix for the issue Muneer presented. JDK9 doesn't exhibit these
> failures as it has the fix to be backported.

As I understood it, 8180904 reports that a whole bunch of tests fail if 
run in agentvm mode. The current backport would enable agentvm mode and 
hence all those tests would start to fail.

Did I misunderstand something?

Thanks,
David


> Comparing the runs without and with the patch - this is on x86 - I get
> essentially the same on aarch64:
> 
> 0: JTwork-without  pass: 680; fail: 44; error: 3; not run: 4
> 1: JTwork-with  pass: 718; fail: 6; error: 2; not run: 5
> 
> 0      1      Test
> fail   pass   compiler/jsr292/PollutedTrapCounts.java
> fail   pass   compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java#id0
> fail   pass   compiler/loopopts/UseCountedLoopSafepoints.java
> pass   fail   compiler/rtm/locking/TestRTMLockingThreshold.java#id0
> fail   pass   compiler/types/correctness/OffTest.java#id0
> fail   pass   gc/TestVerifySilently.java
> fail   pass   gc/TestVerifySubSet.java
> fail   pass   gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java
> fail   pass   gc/class_unloading/TestG1ClassUnloadingHWM.java
> fail   pass   gc/ergonomics/TestDynamicNumberOfGCThreads.java
> fail   pass   gc/g1/TestEagerReclaimHumongousRegions.java
> fail   pass   gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java
> fail   pass   gc/g1/TestEagerReclaimHumongousRegionsWithRefs.java
> fail   pass   gc/g1/TestG1TraceEagerReclaimHumongousObjects.java
> fail   pass   gc/g1/TestGCLogMessages.java
> fail   pass   gc/g1/TestHumongousAllocInitialMark.java
> fail   pass   gc/g1/TestPrintGCDetails.java
> fail   pass   gc/g1/TestPrintRegionRememberedSetInfo.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData00.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData05.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData10.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData15.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData20.java
> fail   pass   gc/g1/TestShrinkAuxiliaryData25.java
> fail   pass   gc/g1/TestShrinkDefragmentedHeap.java#id0
> fail   pass   gc/g1/TestStringDeduplicationAgeThreshold.java
> fail   pass   gc/g1/TestStringDeduplicationFullGC.java
> fail   pass   gc/g1/TestStringDeduplicationInterned.java
> fail   pass   gc/g1/TestStringDeduplicationPrintOptions.java
> fail   pass   gc/g1/TestStringDeduplicationTableRehash.java
> fail   pass   gc/g1/TestStringDeduplicationTableResize.java
> fail   pass   gc/g1/TestStringDeduplicationYoungGC.java
> fail   pass   gc/g1/TestStringSymbolTableStats.java
> fail   pass   gc/logging/TestGCId.java
> fail   pass   gc/whitebox/TestWBGC.java
> fail   pass   runtime/ErrorHandling/TestOnOutOfMemoryError.java#id0
> fail   pass   runtime/NMT/JcmdWithNMTDisabled.java
> fail   pass   runtime/memory/ReserveMemory.java
> pass   ---    sanity/WhiteBox.java
> fail   pass   serviceability/attach/AttachWithStalePidFile.java
> fail   pass   serviceability/jvmti/TestRedefineWithUnresolvedClass.java
> error  pass   serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java#id0
> 
> 
> I find that compiler/rtm/locking/TestRTMLockingThreshold.java produces
> inconsistent results on my machine, regardless of whether or not the
> patch is applied.
> 
> BR
>    Stuart
> 
> 
> On 1 June 2017 at 06:39, David Holmes <david.holmes at oracle.com> wrote:
>> Thanks for that information Muneer, that is an unpleasant surprise.
>>
>> Stuart: I think 8180904 has to be fixed before this backport can take place.
>>
>> Thanks,
>> David
>> -----
>>
>>
>> On 1/06/2017 2:31 PM, Muneer Kolarkunnu wrote:
>>>
>>> Hi David and Stuart,
>>>
>>> I recently reported one bug[1] for the same issue and listed which all
>>> test cases are failing with agentvm.
>>> I tested in Oracle.Linux.7.0 x64.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180904
>>>
>>> Regards,
>>> Muneer
>>>
>>> -----Original Message-----
>>> From: David Holmes
>>> Sent: Thursday, June 01, 2017 7:04 AM
>>> To: Stuart Monteith; hotspot-dev Source Developers
>>> Subject: Re: RFR 8u backport: 8077608: [TESTBUG] Enable Hotspot jtreg
>>> tests to run in agentvm mode
>>>
>>> Hi Stuart,
>>>
>>> This looks like an accurate backport of the change.
>>>
>>> My only minor concern is if there may be tests in 8u that are no longer in
>>> 9 which may not work with agentvm mode.
>>>
>>> What platforms have you tested this on?
>>>
>>> Thanks,
>>> David
>>>
>>> On 31/05/2017 11:19 PM, Stuart Monteith wrote:
>>>>
>>>> Hello,
>>>>      Currently the jdk8u codebase fails some JTreg Hotspot tests when
>>>> running in the -agentvm mode. This is because the ProcessTools class
>>>> is not passing the classpath. There are substantial time savings to be
>>>> gained using -agentvm over -othervm.
>>>>
>>>> Fortunately, there was a fix for jdk9 (8077608) that has not been
>>>> backported to jdk8u.  The details are as follows:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017937.h
>>>> tml
>>>> https://bugs.openjdk.java.net/browse/JDK-8077608
>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af2a1e9f08f3
>>>>
>>>> The patch just needed a slight change, to remove the change to the
>>>> file "test/compiler/uncommontrap/TestUnstableIfTrap.java" as that test
>>>> doesn't exist on jdk8u.
>>>>
>>>> My colleague Ningsheng has kindly hosted the change here:
>>>>
>>>>        http://cr.openjdk.java.net/~njian/8077608/webrev.00
>>>>
>>>>
>>>> BR,
>>>>       Stuart
>>>>
>>