8195600: [Graal] jdi tests timeouts with Graal because debuggee vm is not resumed

[Chris Plummer]

I'm not sure. You could problem list it, but then the question is which 
bug to problem list it under, JDK-8195600 or JDK-8207267 (in which case 
JDK-8195600 would be closed). I'd hate to see a separate CR for every 
test that fails due to graal unexpectedly executing java code. But then 
JDK-8207267 seems to be more about getting rid of the use of @requires 
once libgraal is added, not going through the graal problemlist.

Chris

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 at openjdk.java.net on behalf of dean.long at oracle.com" <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of dean.long at 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 at 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
>      >>>>>
>      >>>>>
>      >>>>
>      >>>
>      >>
>      >>
>      >
>      >
>      
>      
>      
>
>