Re: A hotspot patch for stack profiling (frame pointer)

On 13/02/2015 23:26, Brendan Gregg wrote: Thanks Bertrand and John for explaining the invokedynamic issue, and Vladimir for filing the bug. I'll reply here (I don't have a JBS account; I would like one!). The profilers I'm using (Linux perf, and Solaris DTrace) can already handle a broken RBP,

Re: A hotspot patch for stack profiling (frame pointer)

On 2/13/15 2:28 PM, Brendan Gregg wrote: G'Day Serguei, On Thu, Jan 15, 2015 at 1:26 PM, serguei.spit...@oracle.com > wrote: On 1/15/15 3:13 AM, Bertrand Delsart wrote: On 14/01/2015 20:12, John Rose wrote:

Re: A hotspot patch for stack profiling (frame pointer)

G'Day Serguei, On Thu, Jan 15, 2015 at 1:26 PM, serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > On 1/15/15 3:13 AM, Bertrand Delsart wrote: > >> On 14/01/2015 20:12, John Rose wrote: >> >>> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart >>> mailto:bertrand.dels...@oracle.com>> >>

Re: A hotspot patch for stack profiling (frame pointer)

Thanks Bertrand and John for explaining the invokedynamic issue, and Vladimir for filing the bug. I'll reply here (I don't have a JBS account; I would like one!). The profilers I'm using (Linux perf, and Solaris DTrace) can already handle a broken RBP, and we see this all the time when profiling

Re: A hotspot patch for stack profiling (frame pointer)

On 1/15/15 3:13 AM, Bertrand Delsart wrote: On 14/01/2015 20:12, John Rose wrote: On Jan 14, 2015, at 6:42 AM, Bertrand Delsart mailto:bertrand.dels...@oracle.com>> wrote: I would not prevent the JITs from using RBP as long as the changeset is not sufficient to guarantee the profiling will wo

Re: A hotspot patch for stack profiling (frame pointer)

Thank you, Bertrand and John I added this conversation to the bug report. Thanks, Vladimir On 1/15/15 3:13 AM, Bertrand Delsart wrote: On 14/01/2015 20:12, John Rose wrote: On Jan 14, 2015, at 6:42 AM, Bertrand Delsart mailto:bertrand.dels...@oracle.com>> wrote: I would not prevent the JITs

Re: A hotspot patch for stack profiling (frame pointer)

On 14/01/2015 20:12, John Rose wrote: On Jan 14, 2015, at 6:42 AM, Bertrand Delsart mailto:bertrand.dels...@oracle.com>> wrote: I would not prevent the JITs from using RBP as long as the changeset is not sufficient to guarantee the profiling will work... and IMHO solving the JSR292 issue will b

Re: A hotspot patch for stack profiling (frame pointer)

On Jan 14, 2015, at 6:42 AM, Bertrand Delsart wrote: > > I would not prevent the JITs from using RBP as long as the changeset is not > sufficient to guarantee the profiling will work... and IMHO solving the > JSR292 issue will be much more intrusive (impacting HotSpot stack walking > code).

Re: A hotspot patch for stack profiling (frame pointer)

Hi, I'm surprised not to see any change related to JSR292 in the webrev. While the fix looks safe (not breaking hotspot), it probably does not work as you expect... and this might make it useless. RBP is used by the JITs to memorize SP before it may be adapted during a call sequence (look fo

Re: A hotspot patch for stack profiling (frame pointer)

Filed RFE: https://bugs.openjdk.java.net/browse/JDK-8068945 Regards, Vladimir On 12/9/14 2:14 AM, Erik Helin wrote: I should also add that I don't have enough knowledge of the compiler internals to review this patch, sorry. Thanks, Erik On 2014-12-09 10:53, Erik Helin wrote: I applied the p

Re: A hotspot patch for stack profiling (frame pointer)

Hi there, I'm the one who started the perf-map-agent project. Thanks, Brendan and all others for having this discussion here. On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > That said, I still don't know how perf creates stack traces. Does it > attach to the process with ptrace or how el

Re: A hotspot patch for stack profiling (frame pointer)

I should also add that I don't have enough knowledge of the compiler internals to review this patch, sorry. Thanks, Erik On 2014-12-09 10:53, Erik Helin wrote: I applied the patch on top of jdk9/hs-comp and created a webrev: http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ I a

Re: A hotspot patch for stack profiling (frame pointer)

> On 8 dec 2014, at 21:31, Brendan Gregg wrote: > > G'Day Staffan, > > On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen > wrote: >> >>> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >>> > [...] >>> >>> And if the VM creates a /tmp/perf-.map file to save information about >>> JITed methods

Re: A hotspot patch for stack profiling (frame pointer)

I applied the patch on top of jdk9/hs-comp and created a webrev: http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ I also successfully run the patch through JPRT. Thanks, Erik On 2014-12-05 20:57, Brendan Gregg wrote: On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg mailto:brenda

Re: A hotspot patch for stack profiling (frame pointer)

On 2014-12-08 21:31, Brendan Gregg wrote: G'Day Staffan, On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen wrote: On 8 dec 2014, at 16:05, Maynard Johnson wrote: [...] And if the VM creates a /tmp/perf-.map file to save information about JITed methods, the perf's post-profiling tool will

Re: A hotspot patch for stack profiling (frame pointer)

On 08/12/14 22:19, Brendan Gregg wrote: > It's a good idea, but I'm not sure the DWARF unwind approach is > suitable for dynamic JIT. I'm usually sampling at 99 Hertz. With > inlined symbols, just the perf.map file can become 10s of Mbytes, and > I assume the DWARF info would be similar. So the fil

Re: A hotspot patch for stack profiling (frame pointer)

G'Day Mikael, On Mon, Dec 8, 2014 at 9:15 AM, Mikael Gerdin wrote: > Maynard, > > > On 2014-12-08 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> corre

Re: A hotspot patch for stack profiling (frame pointer)

G'Day Staffan, On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen wrote: > >> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> correlate

Re: A hotspot patch for stack profiling (frame pointer)

> On 8 dec 2014, at 16:05, Maynard Johnson wrote: > > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symb

Re: A hotspot patch for stack profiling (frame pointer)

Maynard, On 2014-12-08 16:05, Maynard Johnson wrote: On 12/05/2014 05:09 PM, Brendan Gregg wrote: G'Day Volker, On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: Hi Brendan, I'm still not understanding who is taking the actual stack traces (let alone the symbols) in your examples. Is t

Re: A hotspot patch for stack profiling (frame pointer)

On Mon, Dec 8, 2014 at 4:05 PM, Maynard Johnson wrote: > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbo

Re: A hotspot patch for stack profiling (frame pointer)

On 12/05/2014 05:09 PM, Brendan Gregg wrote: > G'Day Volker, > > On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis > wrote: >> Hi Brendan, >> >> I'm still not understanding who is taking the actual stack traces (let >> alone the symbols) in your examples. Is this done by 'perf' itself >> based only

Re: A hotspot patch for stack profiling (frame pointer)

G'Day Volker, On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > Hi Brendan, > > I'm still not understanding who is taking the actual stack traces (let > alone the symbols) in your examples. Is this done by 'perf' itself > based only on the frame pointer? perf is walking the frame pointers

Re: A hotspot patch for stack profiling (frame pointer)

Yes, that's clear. I didn't wanted to propose using "jstack -F" directly. I just wanted to say that it's possible for an external tool to get a "reasonable good" stack trace out of a JVM process at any time and "jstack -F" can be taken as a boilerplate of how to do that. That said, I still don't k

Re: A hotspot patch for stack profiling (frame pointer)

On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg wrote: > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what this > involves, and also to have a working prototype for analysis. Along with an > agent to resolve symbols, this has allowed full stack profiling using Linux >

Re: A hotspot patch for stack profiling (frame pointer)

Just to note that the implementation of “jstack -F” is not at all suitable for profiling since has a very high overhead (it attaches a debugger to the process). /Staffan > On 5 dec 2014, at 20:22, Volker Simonis wrote: > > Hi Brendan, > > I'm still not understanding who is taking the actual

Re: A hotspot patch for stack profiling (frame pointer)

Hi Brendan, I'm still not understanding who is taking the actual stack traces (let alone the symbols) in your examples. Is this done by 'perf' itself based only on the frame pointer? As I wrote before, this is pretty hard to get right for a JVM, but there are good approximations. Have you looked

A hotspot patch for stack profiling (frame pointer)

G'Day, I've hacked hotspot to return the frame pointer, in part to see what this involves, and also to have a working prototype for analysis. Along with an agent to resolve symbols, this has allowed full stack profiling using Linux perf_events. The following flame graphs show the resulting profile