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-boun...@openjdk.java.net on behalf of
dean.l...@oracle.com" <hotspot-compiler-dev-boun...@openjdk.java.net on behalf of
dean.l...@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.l...@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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
