RFR(S): 8174856: [TESTBUG] Missing DefineClass instances
Volker Simonis
volker.simonis at gmail.com
Thu Feb 16 11:16:42 UTC 2017
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