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

Stuart Monteith stuart.monteith at linaro.org
Fri Jun 2 13:55:55 UTC 2017 

Hi David,
   Good point - runtime/os/AvailableProcessors.java does some custom
execution that misses out the classpath. It is easy enough to fix, but
there might be follow on patches to backport.
compiler/rtm/locking/TestRTMLockingThreshold.java might also have some
trouble.

I'm investigating further.


Thanks,
  Stuart

On 2 June 2017 at 10:30, David Holmes <david.holmes at oracle.com> wrote:
> On 2/06/2017 7:17 PM, Stuart Monteith wrote:
>>
>> Hi David,
>>     Yes, I was being a bit unclear. The patch includes a fix to allow
>> the tests that fail under -agentvm to pass successfully. Under
>> agentvm, tests that spawn their own processes don't inherit a working
>> classpath, so the patch changes ProcessTools to pass this on. The
>> results I presented before show how the failing tests will then pass
>> with agentvm once the patch is applied.
>
>
> Ah I see. Thanks I missed the significance of the ProcessTools change.
>
>>>> 1: JTwork-with  pass: 718; fail: 6; error: 2; not run: 5
>
> So out of those 8 non-passing tests are any of the failures specifically
> related to using agentvm?
>
> Thanks,
> David
>
>
>> Thanks,
>>      Stuart
>>
>>
>> On 2 June 2017 at 02:36, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> 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
>>>>>>>
>>>>>
>>>
>

More information about the hotspot-dev mailing list