RFR(S): 8174856: [TESTBUG] Missing DefineClass instances

[David Holmes]

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
>>>
>>