Re: RFR(xs): 8213834: JVMTI ResourceExhausted should not be posted in CompilerThread

On 22/11/2018 5:36 pm, Thomas Stüfe wrote: Hi JC, On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote: Hi Thomas, I actually agree with not using the service thread to be honest, resource exhaustion seems to be something you'd want to know sooner than later. How about we do both? -

Re: RFR(xs): 8213834: JVMTI ResourceExhausted should not be posted in CompilerThread

Hi JC, On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote: > > Hi Thomas, > > > I actually agree with not using the service thread to be honest, resource > exhaustion seems to be something you'd want to know sooner than later. > > How about we do both? > - Fix it now so that the compiler thread

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

Thanks a bunch, JC ! Could have a Reviewer also take a look at this please ? - Jini. On 11/21/2018 11:05 PM, JC Beyler wrote: Hi Jini, Looks good to me, thanks for fixing the nits :) Thanks, Jc On Wed, Nov 21, 2018 at 9:29 AM Jini George > wrote: The

Re: Suggested improvement to X86Frame.getInterpreterFrameBCI

PS: should have added a new X86Frame constructor really, may have just been put off because there is already a four address constructor so would have had to add dummy argument or something. On Wed, 21 Nov 2018 at 19:15, David Griffiths wrote: > Hi, thanks, apart from adding a setter for R13 in

Re: Suggested improvement to X86Frame.getInterpreterFrameBCI

Hi, thanks, apart from adding a setter for R13 in X86Frame, the other half of the fix is this: publicFrame getCurrentFrameGuess(JavaThread thread, Address addr) { ThreadProxy t = getThreadProxy(addr); AMD64ThreadContext context = (AMD64ThreadContext) t.getContext();

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

The modified webrev with the RuntimeException and the nit removed is at: http://cr.openjdk.java.net/~jgeorge/8213323/webrev.01/ Thanks! Jini. On 11/12/2018 12:41 PM, Jini George wrote: Thank you very much, JC, for looking into this.

Suggested improvement to X86Frame.getInterpreterFrameBCI

Hi, I'm new to this mailing list and working on a project that makes use of the SA classes to get stack traces from a paused in flight JVM (we can't use JDWP). I have observed that if the top frame is in the interpreter it reports the BCI and line number incorrectly. This is because

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

On Wed, 21 Nov 2018 at 10:20, Severin Gehwolf wrote: > > On Wed, 2018-11-21 at 06:47 +, Andrew Hughes wrote: > > On Mon, 19 Nov 2018 at 15:39, Severin Gehwolf wrote: > > > > snip... > > > > > > > > Two reasons: (1) JDK-8140482 isn't a small change. (2) The patch > > > doesn't apply

Re: Proposal: Always-on Statistical History

Thank you Mario. I will take a closer look at JFR. On Wed, Nov 21, 2018 at 9:19 AM Mario Torre wrote: > > I didn't have time to read the patch fully, but just as a quick look, > it seems like you can create JFR events to log the same information, > JFR will take care of all the infrastructure. >

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

On 2018-11-20 16:49, Alexey Ivanov wrote: Hi Ali, Magnus, I absolutely agree this change has to be reviewed by someone from serviceability. There are several options: 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows

Re: Access to jdk.hotspot.agent classes in Java 9?

Ok, thanks, that worked and I can now use them again. Cheers, David On Tue, 20 Nov 2018 at 20:47, David Holmes wrote: > Hi David, > > The sun.jvm.hotspot classes have always been a JDK internal API. What > has changed in Java 9 is that the Java Platform Module System now > enforces that

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

On Wed, 2018-11-21 at 06:47 +, Andrew Hughes wrote: > On Mon, 19 Nov 2018 at 15:39, Severin Gehwolf wrote: > > snip... > > > > > Two reasons: (1) JDK-8140482 isn't a small change. (2) The patch > > doesn't apply cleanly[1] from JDK 9 so would be some work to get the > > pre-requisite in. >

Re: Proposal: Always-on Statistical History

I didn't have time to read the patch fully, but just as a quick look, it seems like you can create JFR events to log the same information, JFR will take care of all the infrastructure. So for example, every time you need to call set_value_in_record this is would be instead a JFR. Again, I only

Re: Proposal: Always-on Statistical History

Hi all, (I combine my replies here, since most of your feedback was similar). Thank you all for the feedback! If I understand you correctly, the consensus is that you do not wish to introduce another data collection backend beside JFR. And that, should JFR lack features we miss, we rather