RFR(S): 8174856: [TESTBUG] Missing DefineClass instances
Dmitry Dmitriev
dmitry.dmitriev at oracle.com
Thu Feb 16 11:35:53 UTC 2017
Yes, sure, I will sponsor this change after we get "R"eview of the
latest webrev. Thanks!
Dmitry
On 16.02.2017 14:16, Volker Simonis wrote:
> On Thu, Feb 16, 2017 at 11:26 AM, Dmitry Dmitriev
> <dmitry.dmitriev at oracle.com> wrote:
>> Volker, test change with @requires looks good!
>>
> Thanks! Can you please sponsor the change?
>
>> vm.compMode is an extension Jtreg requires name, so it's not listed in Jtreg
>> documentation. It seems that the only reliable way is to look into hotspot
>> test suite config file hotspot/test/TEST.ROOT. This file mention additional
>> properties for hs tests:
>> requires.extraPropDefns = ../../test/jtreg-ext/requires/VMProps.java
>> [../../closed/test/jtreg-ext/requires/VMPropsExt.java]
>>
>> VMProps.java define following properties:
>> map.put("vm.flavor", vmFlavor());
>> map.put("vm.compMode", vmCompMode());
>> map.put("vm.bits", vmBits());
>> map.put("vm.flightRecorder", vmFlightRecorder());
>> map.put("vm.simpleArch", vmArch());
>> map.put("vm.debug", vmDebug());
>> map.put("vm.jvmci", vmJvmci());
>> map.put("vm.emulatedClient", vmEmulatedClient());
>> map.put("vm.cpu.features", cpuFeatures());
>> vmGC(map); // vm.gc.X = true/false
>>
>> I hope this helps in the future!
>>
> Sure, that's helpfull!
>
>> Thanks,
>> Dmitry
>>
>>
>> On 16.02.2017 13:06, Volker Simonis wrote:
>>> On Wed, Feb 15, 2017 at 6:46 PM, Dmitry Dmitriev
>>> <dmitry.dmitriev at oracle.com> wrote:
>>>> Hello Volker,
>>>>
>>>> I think this can be simplified by using isComp() method of Platform class
>>>> from jdk.test.lib package(test/lib/jdk/test/lib/Platform.java). Also, I
>>>> think it is possible to specify VM mode in @requires tag(I think it's
>>>> best
>>>> solution to exclude test with "-Xcomp" flag), but I need to check that
>>>> tomorrow.
>>>>
>>> Hi Dmitry,
>>>
>>> thanks for you comments. I think you are right and I agree that a
>>> @requires tag is the simplest and most effective way of excluding
>>> these test in -Xcomp mode. I use @requires vm.compMode != "Xcomp".
>>> Please find the new webrev here:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174856.v2/
>>>
>>> By the way, is there an up to date list of all the available require
>>> names? I only found
>>> http://openjdk.java.net/jtreg/tag-spec.html#requires_names but it
>>> doesn't contain vm.compMode != "Xcomp" for example.
>>>
>>> Regards,
>>> Volker
>>>
>>>> Thank you,
>>>> Dmitry
>>>>
>>>>
>>>> On 15.02.2017 20:32, Volker Simonis wrote:
>>>>> Hi,
>>>>>
>>>>> so here's an alternative version which doesn't execute the tests in
>>>>> -Xcomp
>>>>> mode:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174856.v1/
>>>>>
>>>>> Instead of using a wrapper test which seems overly complicated to me
>>>>> :) I just use MX to query the command line and return if either
>>>>> '-Xcomp' or '-XX:-UseInterpreter' was specified.
>>>>>
>>>>> Please choose whichever of the two versions you like.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>> PS: it would be great if you could run the exact test that failed
>>>>> before just in case there will be other problems as well. I've just
>>>>> checked that the test now succeed in both, normal and '-Xcomp' mode.
>>>>>
>>>>>
>>>>> On Wed, Feb 15, 2017 at 10:17 AM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>>> Hi Volker,
>>>>>>
>>>>>> On 15/02/2017 5:51 PM, Volker Simonis wrote:
>>>>>>> On Wed, Feb 15, 2017 at 12:46 AM, David Holmes
>>>>>>> <david.holmes at oracle.com>
>>>>>>> wrote:
>>>>>>>> Hi Volker,
>>>>>>>>
>>>>>>>> Can we just skip the test in -Xcomp mode?
>>>>>>>>
>>>>>>> That would be fine for me, but how would I detect that? -Xcomp is not
>>>>>>> a VM flag, it is specially handled at startup and sets the following
>>>>>>> actual flags:
>>>>>>>
>>>>>>> case _comp:
>>>>>>> UseInterpreter = false;
>>>>>>> BackgroundCompilation = false;
>>>>>>> ClipInlining = false;
>>>>>>> if (TieredCompilation) {
>>>>>>> Tier3InvokeNotifyFreqLog = 0;
>>>>>>> Tier4InvocationThreshold = 0;
>>>>>>> }
>>>>>>>
>>>>>>> Do you think it is safe to check for all these flags and skip the test
>>>>>>> if they are set correspondingly?
>>>>>>
>>>>>> A simpler approach would be to run a wrapper test in driver mode, so no
>>>>>> VM
>>>>>> flags are passed through, and then exec the real test in a VM with
>>>>>> minimal
>>>>>> flags set.
>>>>>>
>>>>>>> Why do you actually think we should skip the test in -Xcomp mode? Do
>>>>>>> you think it became too complicated/unstable? The good thing about
>>>>>>> running it in -Xcomp mode is that it now also checks that we get rid
>>>>>>> of the instance classes which are referenced by the nmethods.
>>>>>>
>>>>>> Xcomp is a stress mode that can sometimes change the normal way things
>>>>>> work,
>>>>>> so we sometimes end up not actually testing what we intended to test
>>>>>> when
>>>>>> run in Xcomp mode.
>>>>>>
>>>>>> In this case I don't know enough about what is happening to evaluate
>>>>>> the
>>>>>> techniques you have used to deal with Xcomp mode. So I can't review
>>>>>> this
>>>>>> as-is.
>>>>>>
>>>>>> Would love to get other opinions on this.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> But as I said, I'm open for both solutions. Please let me know what
>>>>>>> you
>>>>>>> think.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15/02/2017 4:31 AM, Volker Simonis wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> can I please have a reviewer and sponsor for the following fix:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8174856/
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8174856
>>>>>>>>>
>>>>>>>>> The runtime/Metaspace/DefineClass.java test introduced with 8173743
>>>>>>>>> fails if run in '-Xcomp' mode. There are actually two problems we
>>>>>>>>> observe:
>>>>>>>>>
>>>>>>>>> - for the "defineClass" and "defineClassParallel" cases we observe
>>>>>>>>> fewer instance classes than expected. This is because in -Xcomp mode
>>>>>>>>> the functions get compiled and deoptimized, but because we don't
>>>>>>>>> really use the defined classes, they are already removed before our
>>>>>>>>> first check. This problem can be easily fixed by inserting the
>>>>>>>>> classes
>>>>>>>>> into a global static list.
>>>>>>>>>
>>>>>>>>> - for the "redefineClass" case, if run in -Xcomp mode, the problem
>>>>>>>>> is
>>>>>>>>> that we get 10 different nmethods for each version of the class
>>>>>>>>> redefinition, and these nmethods keep the instance classes alive,
>>>>>>>>> even
>>>>>>>>> after their activation has been removed from the stack. The problem
>>>>>>>>> can be solved by manually deoptimizing the methods and subsequent
>>>>>>>>> sweeping of the code cache. Notice that this has to be done at least
>>>>>>>>> three times, because during every sweep process, the nmethods first
>>>>>>>>> transition from "non-entrant" to "zombie" before they are finally
>>>>>>>>> cleaned.
>>>>>>>>>
>>>>>>>>> Thank you and best regards,
>>>>>>>>> Volker
>>>>>>>>>
More information about the hotspot-runtime-dev
mailing list