Hi Alan,
Was wondering if you had had a chance to look at this please?
Thanks
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leon...@uk.ibm.com
From: Andrew Leonard/UK/IBM
To: Alan Bateman
Cc: serviceability-dev@openjdk.j
Hi David,
I think this change makes sense.
We'll test it and take a closer look at it.
First impression is good.
Best regards,
Martin
> -Original Message-
> From: David Holmes
> Sent: Dienstag, 27. August 2019 00:21
> To: serguei.spit...@oracle.com; serviceability-dev d...@openjdk.jav
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, "
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-82072
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 libgr
