[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: 8195600: [Graal] jdi tests timeouts with Graal because debuggee vm is not resumed
From:       dean.long () oracle ! com
Date:       2019-08-27 22:14:36
Message-ID: afed0cc8-0bb4-9175-2f67-670cf292e6a8 () oracle ! com
[Download RAW message or body]

I don't have a strong opinion either way.   It's too bad we don't have 
resource management features that would allow setting a memory limit on 
the test or app while allowing the rest of the JVM to use memory 
unrestricted.   That might solve a lot of these OOM problems. Even after 
we move to libgraal, that still doesn't guarantee that reaching an OOM 
state is a recoverable state for the JVM.

Is there a way to rewrite these tests to cover what they need to cover, 
without consuming all of memory (maybe a class unloading WhiteBox API)?   
Or maybe some kind of hint, like a command-line flag, that says the test 
will consume all of memory.   That way any critical services like the 
JVMCI compiler could use that hint to eagerly initialize before the test 
starts.

dl

On 8/27/19 2:08 PM, Daniil Titov wrote:
> Hi Dean and Chris,
> 
> Just wanted to check with you would it be OK now to add this issue to
> Graal-specific problem list, as Dean suggested in one of  the previous emails,
> while the proposal about introducing new options for @requires is being discussed?
> 
> -Thanks!
> --Daniil
> 
> 
> 
> On 8/9/19, 3:37 PM, "hotspot-compiler-dev-bounces@openjdk.java.net on behalf of \
> dean.long@oracle.com" <hotspot-compiler-dev-bounces@openjdk.java.net on behalf of \
> dean.long@oracle.com> wrote: 
> Good question  When we have libgraal, there will still be an option (at
> least for debugging) to turn it off and use Graal the same way we do
> now, so it seems like the @requires would need to take that into account
> once we have libgraal.  Maybe we will need a new "vm.libgraal.enabled"
> or make "vm.graal.enabled" be false for libgraal?
> 
> It does seem a little backwards to require tests to know about the OOM
> handling details of different JVM features.  Instead, how about if we
> let the test assert that it requires "vm.no-background-oom" or whatever,
> and let the JVM decide if it supports it.
> 
> CC'ing hotspot-compiler-dev.
> 
> dl
> 
> On 8/8/19 7:42 PM, Chris Plummer wrote:
> > Actually looking at JDK-8207267 a little closer, it looks like it's
> > job is to re-enable tests that have been disabled with @requires
> > !vm.graal.enabled, so it looks like we have two different approaches
> > going in here. Which is preferred? If the preference is to problem
> > list, do we want to undo JDK-8207261 (except use JDK-8196611 as the CR).
> > 
> > Chris
> > 
> > On 8/8/19 5:08 PM, Chris Plummer wrote:
> > > That sounds like a better approach to me.
> > > 
> > > thanks,
> > > 
> > > Chris
> > > 
> > > On 8/8/19 4:33 PM, dean.long@oracle.com wrote:
> > > > This is the kind of failure that is expected to go away with
> > > > libgraal. You can add the tests to the Graal-specific problem list
> > > > (see JDK-8196611) and they should be re-enabled with libgraal (see
> > > > JDK-JDK-8207267).
> > > > 
> > > > dl
> > > > 
> > > > On 8/8/19 10:21 AM, Chris Plummer wrote:
> > > > > Hi Daniil,
> > > > > 
> > > > > My only objection is at some point it seems we need to be able to
> > > > > run these tests with graal (and other tests that have been disabled
> > > > > due to graal) because graal might be the only compiler, and we'll
> > > > > lose test coverage without these tests. Currently we have 260 jtreg
> > > > > tests disabled due to graal. I'm not sure to what extent they are
> > > > > waiting on graal fixes or otherwise have a bug filed to eventually
> > > > > fix them. Would be nice if we had a process in place to make sure
> > > > > these issues are eventually addressed. That fact that tests that
> > > > > exhaust memory in general seem to be incompatible with graal would
> > > > > to be the bigger issue that needs to be addressed.
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > Chris
> > > > > 
> > > > > On 8/7/19 3:38 PM, Daniil Titov wrote:
> > > > > > Please review the change that fixes the failing tests when running
> > > > > > with Graal. The issue originally
> > > > > > included several vmTestbase/nsk/jdi tests but only 2 of them still
> > > > > > fail:
> > > > > > -
> > > > > > vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java
> > > > > >                 
> > > > > > -
> > > > > > vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
> > > > > >  
> > > > > > The problem with these two tests is that they consume all memory
> > > > > > to force the class unloading that
> > > > > > results in the exception during JVMCI compiler initialization and
> > > > > > the test failure.
> > > > > > The fix filters these tests out to not run with Graal compiler.
> > > > > > 
> > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8195600/webrev.01/
> > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195600
> > > > > > 
> > > > > > Thanks,
> > > > > > Daniil
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]