RFR 8u backport: 8077608: [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode
Stuart Monteith
stuart.monteith at linaro.org
Fri Jun 2 09:17:23 UTC 2017
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.
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