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

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8195600: [Graal] jdi tests timeouts with Graal because debuggee vm is not resumed
From:       dean.long () oracle ! com
Date:       2019-08-09 22:37:03
Message-ID: 3c292c47-2962-d79b-e99d-7c3b7376ac5e () oracle ! com
[Download RAW message or body]

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]