Re: system profilers and incomplete stacks

G'Day Serguei, On Mon, Jun 16, 2014 at 10:45 PM, serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > Hi Brendan, > > We are aware of these issues and work with the Solaris team to fix them in > JDK 9. > One is the frame pointer is used by the server compiler as a general > purpose

Re: system profilers and incomplete stacks

Hi Brendan, I'm not quite seeing the complete context here so a few queries: 1. Which platform are you running Dtrace on? (hotspot has to provide helper d-scripts to allow Dtrace to walk Java stacks) 2. What are perf-events? How do they try to walk stacks? 3. Does "jstack -m" show full stack

Re: system profilers and incomplete stacks

Hi Brendan, We are aware of these issues and work with the Solaris team to fix them in JDK 9. One is the frame pointer is used by the server compiler as a general purpose register on intel. Another is about the virtual (or inlined) frames. There are a couple of related bugs: https://bugs.o

Re: system profilers and incomplete stacks

Thanks but no, I'm aware of that bug and workarounds (I'm using the LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which isn't mentioned in the bug comments, but probably should be). That bug is about missing symbols, but the stacks shown in that bug still go all the way to threa

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

Thanks for closing the loop on my late review. Thumbs up! Dan On 6/16/14 11:39 AM, Staffan Larsen wrote: On 16 jun 2014, at 17:01, Daniel D. Daugherty mailto:daniel.daughe...@oracle.com>> wrote: > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ test/com/sun/jdi/VMCo

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

On 16 jun 2014, at 17:01, Daniel D. Daugherty wrote: > > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ > > test/com/sun/jdi/VMConnection.java > line 62: System.out.println("vmOpts: "+vmOpts); > line 67: System.out.println("javaOpts: "+javaOpts); >

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ test/com/sun/jdi/VMConnection.java line 62: System.out.println("vmOpts: "+vmOpts); line 67: System.out.println("javaOpts: "+javaOpts); line 68: if (javaOpts != null) { Indent off by

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

Thanks David! On 16 jun 2014, at 14:22, David Holmes wrote: > Looks okay to me. > > Thanks, > David > > On 16/06/2014 9:59 PM, Staffan Larsen wrote: >> I would appreciate a Review of this change. >> >> Thanks, >> /Staffan >> >> On 11 jun 2014, at 10:00, Staffan Larsen >

Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind

Erik, It's better to check lock-file age rather than maintain in-process timeout variable, it guards the test from the situation when lock file was not removed from the previous run for some reason. see jdk/test/sun/management/jdp/JdpDoSomething.java -Dmitry On 2014-06-16 14:32, Erik Gahlin

Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind

Erik, It should work see e.g. hotspot/test/runtime/RedefineFinalizer you might need to add -Xbootclasspath/a:tools.jar to @run and -XDignore.symbol.file to @compile -Dmitry On 2014-06-16 14:32, Erik Gahlin wrote: > Yekaterina Kantserova skrev 13/06/14 12:59: >> Erik, >> >> is there some re

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

Looks okay to me. Thanks, David On 16/06/2014 9:59 PM, Staffan Larsen wrote: I would appreciate a Review of this change. Thanks, /Staffan On 11 jun 2014, at 10:00, Staffan Larsen mailto:staffan.lar...@oracle.com>> wrote: I realized that the code in VMConnection does not take into account th

Re: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

I would appreciate a Review of this change. Thanks, /Staffan On 11 jun 2014, at 10:00, Staffan Larsen wrote: > I realized that the code in VMConnection does not take into account the > test.java.opts property as it should. > > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.

Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind

On 16 jun 2014, at 12:32, Erik Gahlin wrote: > Yekaterina Kantserova skrev 13/06/14 12:59: >> Erik, >> >> is there some reason why we need to keep MonitorVmStartTerminate.sh? I've >> moved the JTreg header to MonitorVmStartTerminate.java > Hi Katja, > > That's how I did the test initially, an

Re: system profilers and incomplete stacks

I think this is the bug you are looking at: https://bugs.openjdk.java.net/browse/JDK-7187999, but I’ll defer to someone else to confirm. /Staffan On 16 jun 2014, at 12:47, Roland Westrelin wrote: > Forwarding to serviceability alias where this question belongs I think. > > Begin forwarded m

Fwd: system profilers and incomplete stacks

Forwarding to serviceability alias where this question belongs I think. Begin forwarded message: > From: Brendan Gregg > Subject: system profilers and incomplete stacks > Date: June 12, 2014 at 7:15:54 PM GMT+2 > To: hotspot-compiler-...@openjdk.java.net > > G'Day, > > Is there a way to run ho

Re: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind

Yekaterina Kantserova skrev 13/06/14 12:59: Erik, is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java Hi Katja, That's how I did the test initially, and it works locally, but I could never get it to work in JPRT wit

Re: RFR JDK-8046282: SA update

Thanks for the review, Sundar. regards, Poonam On 6/16/2014 3:54 PM, A. Sundararajan wrote: Hi Poonam, Looks good to me. -Sundar On Monday 16 June 2014 02:45 PM, Poonam Bajaj wrote: Hi Sundar, I have updated the enum classes. The updated webrev is available here: http://cr.openjdk.java.ne

Re: RFR JDK-8046282: SA update

Hi Poonam, Looks good to me. -Sundar On Monday 16 June 2014 02:45 PM, Poonam Bajaj wrote: Hi Sundar, I have updated the enum classes. The updated webrev is available here: http://cr.openjdk.java.net/~poonam/8046282/webrev.01/ Please review the changes and let me know your feedback. Thanks,

Re: RFR JDK-8046282: SA update

Hi Sundar, I have updated the enum classes. The updated webrev is available here: http://cr.openjdk.java.net/~poonam/8046282/webrev.01/ Please review the changes and let me know your feedback. Thanks, Poonam On 6/12/2014 1:25 PM, Poonam Bajaj wrote: Hi Sundar, Is it okay with you if I keep

Re: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call.

Katja, The policy for reviews in the jdk repo is different from the hotspot repo. For the jdk it is ok with a single review. /Staffan On 16 jun 2014, at 09:59, Yekaterina Kantserova wrote: > Hi, > > could I get one more review please? > > Thanks, > Katja > > > On 06/13/2014 02:23 PM, St

Re: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call.

Hi, could I get one more review please? Thanks, Katja On 06/13/2014 02:23 PM, Staffan Larsen wrote: Looks good! Thanks, /Staffan On 13 jun 2014, at 14:15, Yekaterina Kantserova > wrote: Staffan, thanks for your review! The new webrev can be foun