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

Volker Simonis volker.simonis at gmail.com
Wed Feb 15 07:51:42 UTC 2017

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?

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.

But as I said, I'm open for both solutions. Please let me know what you think.


> 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