Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

I did open a bug to track this: https://bugs.openjdk.java.net/browse/JDK-8213834 On Wed, Nov 14, 2018 at 7:38 AM Thomas Stüfe wrote: > > On Wed, Nov 14, 2018 at 6:58 AM David Holmes wrote: > > > > On 14/11/2018 3:37 pm, Thomas Stüfe wrote: > > > On Wed, Nov 14, 2018, 06:32 David Holmes > >

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

On 14/11/2018 4:38 pm, Thomas Stüfe wrote: On Wed, Nov 14, 2018 at 6:58 AM David Holmes wrote: On 14/11/2018 3:37 pm, Thomas Stüfe wrote: On Wed, Nov 14, 2018, 06:32 David Holmes mailto:david.hol...@oracle.com> wrote: Hi Thomas, On 14/11/2018 6:50 am, Thomas Stüfe wrote: >

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

On Wed, Nov 14, 2018 at 6:58 AM David Holmes wrote: > > On 14/11/2018 3:37 pm, Thomas Stüfe wrote: > > On Wed, Nov 14, 2018, 06:32 David Holmes > wrote: > > > > Hi Thomas, > > > > On 14/11/2018 6:50 am, Thomas Stüfe wrote: > > > Hi all, > > > >

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

Hi Chris, I do not think so. The MetaspaceSize we see when we fail has the expected value, it is not downgraded somehow. Also, would that bug apply in a normal VM? Is UseJVMCICompiler not off by default? I think with this bug the chance for this error to happen may increase but the bug itself

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

On 14/11/2018 3:37 pm, Thomas Stüfe wrote: On Wed, Nov 14, 2018, 06:32 David Holmes wrote: Hi Thomas, On 14/11/2018 6:50 am, Thomas Stüfe wrote: > Hi all, > > We have a client using CloudFoundry and its "jvmkill" agent. That is a

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

On 11/13/18 9:32 PM, David Holmes wrote: Hi Thomas, On 14/11/2018 6:50 am, Thomas Stüfe wrote: Hi all, We have a client using CloudFoundry and its "jvmkill" agent. That is a tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which subscribes to the JVMTI ResourceExhausted Event.

Re: What actions are allowed in an JVMTI ResourceExhausted event handler?

Hi Thomas, On 14/11/2018 6:50 am, Thomas Stüfe wrote: Hi all, We have a client using CloudFoundry and its "jvmkill" agent. That is a tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which subscribes to the JVMTI ResourceExhausted Event. In the handler it then does call JVMTI

Re: RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedException

Then consider it reviewed. Thanks! Serguei On 11/13/18 12:50 PM, Daniil Titov wrote: Hi Serguei, Thank you for reviewing this change. You are right, the latest webrev is still v3. Webrev: http://cr.openjdk.java.net/~dtitov/8203174/webrev.03/ Bug:

What actions are allowed in an JVMTI ResourceExhausted event handler?

Hi all, We have a client using CloudFoundry and its "jvmkill" agent. That is a tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which subscribes to the JVMTI ResourceExhausted Event. In the handler it then does call JVMTI FollowReferences() to produce a heap histogram. The thing

Re: RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedException

Hi Serguei, Thank you for reviewing this change. You are right, the latest webrev is still v3. Webrev: http://cr.openjdk.java.net/~dtitov/8203174/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203174 Best regards, Daniil On 11/13/18, 12:05 PM, "serguei.spit...@oracle.com"

Re: RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedException

Hi Daniil, I do not see the latest webrev in this email anymore. Is it still the v3 version? If so then the fix looks good to me. I like the comments you added there as they help. I was also concerned about the compiler issue. Thank you for pointing that it was resolved with the JDK-8195627.

Re: RFR (XS): 8213525: new unit test GetLocalVariable/LocalVars is not stable

Hi Serguei, Changes look good. Chris On 11/12/18 8:06 PM, serguei.spit...@oracle.com wrote: On 11/12/18 20:05, serguei.spit...@oracle.com wrote: Hi Jc, Thank you a lot for

Re: RFR (XS): 8213525: new unit test GetLocalVariable/LocalVars is not stable

Thanks a lot, Jc! Serguei On 11/13/18 08:59, JC Beyler wrote: Ok makes sense then: it is not specified what happens to locals that are out of scope and therefore depending on the compiler/modes/tiers, you could get a different return in

Re: RFR (XS): 8213525: new unit test GetLocalVariable/LocalVars is not stable

Ok makes sense then: it is not specified what happens to locals that are out of scope and therefore depending on the compiler/modes/tiers, you could get a different return in those cases. Webrev looks good to me now :) Jc On Mon, Nov 12, 2018 at 8:06 PM serguei.spit...@oracle.com <

Re: [8u] RFR: 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c

On Tue, 2018-11-13 at 10:46 +0530, Jini George wrote: > Looks good to me, Severin. Thanks for the review! I believe I still need a review from a JDK 8u Reviewer: http://openjdk.java.net/census#jdk8u Thanks, Severin > While looking at this, I realized that the code improvement change of >