Re: RFR 8171119: Low-Overhead Heap Profiling

Hi JC, I have looked through your changes. In threadLocalAllocBuffer.cpp: 349 HeapWord* ThreadLocalAllocBuffer::allocate_sampled_object(size_t size) { 350 Thread* thread = myThread(); 351 thread->tlab().set_back_allocation_end(); 352 HeapWord* result =

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi, On Mon, 2018-05-14 at 13:02 -0700, JC Beyler wrote: > Hi Robbin and all, > > Thank you for your continuous help! > > Done then! Here is the new webrev: > http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.20/ > > and the incremental is: >

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi Robbin and all, Thank you for your continuous help! Done then! Here is the new webrev: http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.20/ and the incremental is: http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.19_20/ Thanks again all! Jc On Mon, May 14, 2018 at 12:43 PM

Re: RFR 8171119: Low-Overhead Heap Profiling

On 2018-05-14 21:37, JC Beyler wrote: Hi Robbin, I did this then, which should be explicit enough, no?        // If we want to be sampling, protect the allocated object with a Handle       // before doing the callback. The callback is done in the destructor of       // the

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi JC, On 2018-05-14 17:09, JC Beyler wrote: Hi Robbin, First off: Thanks for looking! There were 3 comments here and I'll try to address all three :) From easy to more difficult: - The thread state keeping a pointer of the collector: yes I agree but it follows the other collector

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi Robbin, First off: Thanks for looking! There were 3 comments here and I'll try to address all three :) >From easy to more difficult: - The thread state keeping a pointer of the collector: yes I agree but it follows the other collector implementations and with Serguei we tried to keep that

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi JC, I found a .19 which I looked at: src/hotspot/share/gc/shared/collectedHeap.inline.hpp CollectedHeap::allocate_memory This is the only place I found which calls the ~JvmtiSampledObjectAllocEventCollector It is not intuitive with creating a handle for the destructor, I suggest something

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi Jc and Serguei, I have looked at the test fixes and overall they look good. I am a little concerned with some of the comments I read that included “Flakiness” and “unlucky” like this comment in HeapMonitorArrayAllSampledTest.java: // 10% error ensures a sanity test without becoming

Re: RFR 8171119: Low-Overhead Heap Profiling

Hi Jc, I'll make one more pass through the JVMTI and test fixes. However, it would be good if at least one more pair of eyes looked at the tests as they are a big part of the fix. Thanks, Serguei On 5/7/18 19:28, JC Beyler wrote: Hi Vladimir, Good catch, I believe it was used before but no

Re: RFR 8171119: Low-Overhead Heap Profiling

I did not look on JVMTI part and tests. It looks good to me. Where _thread field is used? Thanks, Vladimir On 5/7/18 6:10 PM, JC Beyler wrote: Hi all, With the awesome help of Serguei Spitsyn, we have moved forward on the implementation for JEP-331 and have the following webrev for review:

RFR 8171119: Low-Overhead Heap Profiling

Hi all, With the awesome help of Serguei Spitsyn, we have moved forward on the implementation for JEP-331 and have the following webrev for review: Webrev: http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.18/ Bug: https://bugs.openjdk.java.net/browse/JDK-8171119 It is based on jdk/jdk so

Re: JDK-8171119: Low-Overhead Heap Profiling

>>>> thread doing an event callback. >>>> >>>> Thanks for your help, >>>> Jc >>>> >>>> >>>>> 3) event posting >>>>>- when you post the event to JVMTI >>>>>- in JvmtiObjectAllocEven

Re: JDK-8171119: Low-Overhead Heap Profiling

-dev [mailto: > hotspot-compiler-dev-boun...@openjdk.java.net] *On Behalf Of *JC Beyler > *Sent:* Wednesday, March 28, 2018 11:43 AM > *To:* Erik Österlund <erik.osterl...@oracle.com> > *Cc:* serviceability-dev@openjdk.java.net; hotspot-compiler-dev < > hotspot-compiler-..

RE: JDK-8171119: Low-Overhead Heap Profiling

<erik.osterl...@oracle.com> Cc: serviceability-dev@openjdk.java.net; hotspot-compiler-dev <hotspot-compiler-...@openjdk.java.net> Subject: Re: JDK-8171119: Low-Overhead Heap Profiling Hi all, I've been working on deflaking the tests mostly and the wording in the JVMTI spec. Here is the two

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi JC, Comments are inlined below. On 2018-02-13 06:18, JC Beyler wrote: Hi Erik, Thanks for your answers, I've now inlined my own answers/comments. I've done a new webrev here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.08/

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi JC, Adding Markus Grönlund. On 2018-02-14 01:11, JC Beyler wrote: Hi all, Just to show a bit how to solve the one issue Erik was referring to, consider the following webrev: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.08a/ and incremental is here:

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi JC, Sorry for the delayed reply. Inlined answers: On 2018-02-06 00:04, JC Beyler wrote: Hi Erik, (Renaming this to be folded into the newly renamed thread :)) First off, thanks a lot for reviewing the webrev! I appreciate it! I updated the webrev to:

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi Jc, I've just been browsing this and have a few comments/queries src/hotspot/share/prims/jvmtiHeapTransition.hpp In HeapThreadTransition what are the possible entry states? The primary state is presumably _in_native, but what else is expected? You can't transition from arbitrary states to

Re: Low-Overhead Heap Profiling

Hi JC, Hope I am reviewing the right version of your work. Here goes... src/hotspot/share/gc/shared/collectedHeap.inline.hpp: 159 AllocTracer::send_allocation_outside_tlab(klass, result, size * HeapWordSize, THREAD); 160 161 THREAD->tlab().handle_sample(THREAD, result, size); 162

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi JC, On 01/30/2018 04:22 AM, JC Beyler wrote: - Collectedheap still needs to call AllocTracer to see if it is to be sampled, I can't hide everything in it without a bigger refactor (want me to try?) Yes we need a bigger refactor to do this nicely. I suggested not doing that now, so just

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi Robbin, So I did the changes to move most of the code into the AllocTracer and you can see it incrementally here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.04_05/ And the full webrev here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.05/ Now the issues I see here: -

Re: JDK-8171119: Low-Overhead Heap Profiling

Hi JC, thanks! I'm happy with current state, looks good! Truncated: On 01/27/2018 05:01 AM, JC Beyler wrote: This is strange but I'm assuming it is because we are not working on the same repo? I used: hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap I'll try a new clone on Monday and

JDK-8171119: Low-Overhead Heap Profiling

(Change of subject to contain the bug number :)). New webrev is here: Incremental: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03_04/ Full webrev: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.04/ Inlined are my answers again :). On Fri, Jan 26, 2018 at 5:51 AM, Robbin Ehn

Re: Low-Overhead Heap Profiling

Hi JC, (dropping compiler on mail thread) On 01/26/2018 06:45 AM, JC Beyler wrote: Thanks Robbin for the reviews :) The new full webrev is here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03/ The incremental webrev is here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02_03/

Re: Low-Overhead Heap Profiling

Hi JC, great to see another revision! heapMonitoring.cpp StackTraceData should not contain the oop for 'safety' reasons. When StackTraceData is moved from _allocated_traces: L452 store_garbage_trace(trace); it contains a dead oop. _allocated_traces could instead be a tupel of oop and

Re: Low-Overhead Heap Profiling

On Tue, 2017-11-21 at 13:50 -0800, JC Beyler wrote: > Hi all, > > I have a new webrev here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ > > With the incremental one here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ > > I think I did most items from Thomans and

Re: Low-Overhead Heap Profiling

Hi JC, sorry for the long wait. On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > Dear all, > > Here is the next webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > Incremental since the rebase: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > (I'm

Re: Low-Overhead Heap Profiling

Dear all, Here is the next webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ Incremental since the rebase: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ (I'm still not too familiar with hg so I had to do a fresh rebase so v14 is once the rebase was done and v14a

Re: Low-Overhead Heap Profiling

Hi Jc, sorry for taking a bit long to respond ;) On Mon, 2017-10-23 at 08:27 -0700, JC Beyler wrote: > Dear all, > > Small update this week with this new webrev: >   - http://cr.openjdk.java.net/~rasbold/8171119/webrev.13/ >   - Incremental is here: 

Re: Low-Overhead Heap Profiling

Hi, 325 HeapWord *tlab_old_end = thread->tlab().return end(); Should be something like: 325 HeapWord *tlab_old_end = thread->tlab().end(); Thanks, Robbin On 2017-10-23 17:27, JC Beyler wrote: Dear all, Small update this week with this new webrev:   -

Re: Low-Overhead Heap Profiling

Hi Robbin, That is because version 11 to 12 was only a test change. I was going to write about it and say here are the webrev links: Incremental: http://cr.openjdk.java.net/~rasbold/8171119/webrev.11_12/ Full webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.12/ This change focused

Re: Low-Overhead Heap Profiling

Hi JC, I saw a webrev.12 in the directory, with only test changes(11->12), so I took that version. I had a look and tested the tests, worked fine! First glance at the code (looking at full v12) some minor things below, mostly unused stuff. Thanks, Robbin diff -r 9047e0d726d6

Re: Low-Overhead Heap Profiling

Dear all, Thread-safety is back!! Here is the update webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.10_11/ Full webrev is here: http://cr.openjdk.java.net/~rasbold/8171119/webrev.11/ In order to really test this, I needed to add this so thought now was a good time. It required a few

Re: Low-Overhead Heap Profiling

Hi all, I apologize, I have not yet handled your remarks but thought this new webrev would also be useful to see and comment on perhaps. Here is the latest webrev, it is generated slightly different than the others since now I'm using webrev.ksh without the -N option:

Re: Low-Overhead Heap Profiling

Hi Thomas, First I want to thank you for helping out with this! On 07/03/2017 02:44 PM, Thomas Schatzl wrote: Hi, On Wed, 2017-06-28 at 09:51 +0200, Robbin Ehn wrote: Hi, On 06/21/2017 10:45 PM, JC Beyler wrote: Hi all, First off: Thanks again to Robbin and Thomas for their reviews :)

Re: Low-Overhead Heap Profiling

Hi,   here's a first cut of my thoughts of the latest changes. The compilation problems (at the bottom) prevented me to dig further into it a bit. Please strongly consider providing incremental webrevs, it takes some effort to find changes otherwise. On Tue, 2017-06-27 at 15:04 -0700, JC Beyler

Re: Low-Overhead Heap Profiling

Hi, On Wed, 2017-06-28 at 09:51 +0200, Robbin Ehn wrote: > Hi, > > On 06/21/2017 10:45 PM, JC Beyler wrote: > > > > Hi all, > > > > First off: Thanks again to Robbin and Thomas for their reviews :) > > > > Next, I've uploaded a new webrev: > >

Re: Low-Overhead Heap Profiling

Hi JC, On 06/29/2017 12:15 AM, JC Beyler wrote: B) Incremental changes I guess the most common work flow here is using mq : hg qnew fix_v1 edit files hg qrefresh hg qnew fix_v2 edit files hg qrefresh if you do hg log you will see 2 commits webrev.ksh -r -2 -o my_inc_v1_v2 webrev.ksh -o

Re: Low-Overhead Heap Profiling

Hi, On 06/21/2017 10:45 PM, JC Beyler wrote: Hi all, First off: Thanks again to Robbin and Thomas for their reviews :) Next, I've uploaded a new webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/ Here is an update: - @Robbin, I forgot to say that yes I need to look at

Re: Low-Overhead Heap Profiling

Hi JC, Please, find more comments below. On 6/27/17 21:26, serguei.spit...@oracle.com wrote: Hi JC, Sorry for a latency in reply. I'm going to a 4-week vacation. But I'll try to help you

Re: Low-Overhead Heap Profiling

Hi JC, Sorry for a latency in reply. I'm going to a 4-week vacation. But I'll try to help you occasionally when there will be access to the Internet. On 6/23/17 09:58, JC Beyler wrote: Hi Serguei and all,

Re: Low-Overhead Heap Profiling

Hi, On Wed, 2017-06-21 at 13:45 -0700, JC Beyler wrote: > Hi all, > > First off: Thanks again to Robbin and Thomas for their reviews :) > > Next, I've uploaded a new webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/ > > Here is an update: > > - @Robbin, I forgot to say that yes

Re: Low-Overhead Heap Profiling

Hi JC, Some initial JVMTI-specific questions/comments. I was not able to apply your patch as the are many merge conflicts. Could you, please, re-base it on the latest JDK 10 sources? I think, it would make sense to introduce new

Re: Low-Overhead Heap Profiling

Hi all, On Mon, 2017-06-12 at 11:11 -0700, JC Beyler wrote: > Dear all, > > I've continued working on this and have done the following webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.05/ [...] > Things I still need to do: >    - Have to fix that TLAB case for the FastTLABRefill >  

Re: Low-Overhead Heap Profiling

Hi again, Forgot to say added Dan, he might be interested in JVMTI changes at least. On 06/13/2017 11:19 AM, Robbin Ehn wrote: To get a more potential users it's nice with a Java API and as you say simplifies tests, good. Obviously this is not a public API, but the code for doing it from

Re: Low-Overhead Heap Profiling

Hi JC, This version really makes my happy, awesome work! Since we got no attention from compiler and you manage to get ride of most of the compiler changes, I dropped compiler but added runtime instead. Serguei, when you have time, please chime in. On 06/12/2017 08:11 PM, JC Beyler wrote:

Re: Low-Overhead Heap Profiling

Hi Jc, On 05/22/2017 08:47 PM, JC Beyler wrote: Dear all, I have a new webrev up: http://cr.openjdk.java.net/~rasbold/8171119/webrev.03/ I liked this! Two small things: heapMonitoring.hpp class HeapMonitoring should extend AllStatic heapMonitoring.cpp class MuxLocker should extend

Re: Low-Overhead Heap Profiling

Dear all, I have a new webrev up: http://cr.openjdk.java.net/~rasbold/8171119/webrev.03/ This webrev has, I hope, fixed a lot of the comments from Robbin: - The casts normally are all C++ style - Moved this to jdk10-hs - I have not tested slowdebug yet, hopefully it does not break there

Re: Low-Overhead Heap Profiling

Dear Robbin, Thank you for the answers, much appreciated :) Jc On Tue, May 16, 2017 at 5:20 AM, Robbin Ehn wrote: > Just a few answers, > > On 05/15/2017 06:48 PM, JC Beyler wrote: > >> Dear all, >> >> I've updated the webrev to: >>

Re: Low-Overhead Heap Profiling

Just a few answers, On 05/15/2017 06:48 PM, JC Beyler wrote: Dear all, I've updated the webrev to: http://cr.openjdk.java.net/~rasbold/8171119/webrev.02/ I'll look at this later, thanks! Robbin, I believe I have addressed most of

Re: Low-Overhead Heap Profiling

Robbin, Thank you for forwarding! I will review it. Thanks, Serguei On 5/4/17 02:13, Robbin Ehn wrote: Hi, To me the compiler changes looks what is expected. It would be good if someone from compiler could take a look at that. Added compiler to mail thread. Also adding Serguei, It would be

Re: Low-Overhead Heap Profiling

Hi, To me the compiler changes looks what is expected. It would be good if someone from compiler could take a look at that. Added compiler to mail thread. Also adding Serguei, It would be good with his view also. My initial take on it, read through most of the code and took it for a ride.

Re: Low-Overhead Heap Profiling

Hi all, I've added size information to the allocation sampling system. This allows the callback to remember the size of each sampled allocation. http://cr.openjdk.java.net/~rasbold/8171119/webrev.01/ The new webrev.01 also adds the actual heap monitoring sampling system in files:

Re: Low-Overhead Heap Profiling

Hi all, I worked on getting a few numbers for overhead and accuracy for my feature. I'm unsure if here is the right place to provide the full data, so I am just summarizing here for now. - Overhead of the feature Using the Dacapo benchmark (http://dacapobench.org/). My initial results are that

Re: Low-Overhead Heap Profiling

Working on it. I hope to have something to share in the next couple of weeks. Jeremy On Wed, Aug 12, 2015 at 4:28 AM, Kees Jan Koster kjkos...@gmail.com wrote: Guys, This piqued my interest. Where can I find the draft JEP and the sources for this, please? Kees Jan On 4 Aug 2015, at

Re: Low-Overhead Heap Profiling

Guys, This piqued my interest. Where can I find the draft JEP and the sources for this, please? Kees Jan On 4 Aug 2015, at 23:22, Jeremy Manson jeremyman...@google.com wrote: Thanks, Staffan. I've been tinkering with a draft JEP, but it has been going slowly because of other craziness

Re: Low-Overhead Heap Profiling

Hi, Sorry for being away for so long. If memory serves me right then the current AllocObjectInNewTLAB JFR event was written as a way to quickly get some allocation profiling information with a minimum of VM changes. It probably also carried over to Hotspot from JRockit. I agree that we can

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 2:23 PM, Tony Printezis tprinte...@twitter.com wrote: BTW, Could we get a reaction from the Oracle folks on this? I contacted Staffan (who is probably the right person) offline, and he is, apparently, on vacation until the beginning of August. Unless there is

Re: Low-Overhead Heap Profiling

Hi Jeremy, The answer to that is not to use safepoint-biased execution profilers, I think. Thank you for the advice. I’ve been advocating for a number of years that people understand the sampling bias that exists in all profilers. I also would consider safe point bias being the most

Re: Low-Overhead Heap Profiling

Another thought. Since: - It would be kind of surprising for Thread-allocated_bytes() to be different from the number used as the interval for tracking (e.g., if your interval is, say, 512K, you check allocated bytes, it says 0, you allocate 512K, you check allocated bytes, it says 512K, but no

Re: Low-Overhead Heap Profiling

Hi Jeremy, Sorry I wasn’t so clear, it’s not about collection, it’s about allocation. In this regard it’s not about about size, it’s about the frequency. People tend allocate small objects frequently and they will avoid allocating large objects frequently. The assumption is, large is expensive

Re: Low-Overhead Heap Profiling

Hi Tony, I would think that the size based sampling would create a size based bias in your sampling. That’s actually true. And this could be good (if you’re interested in what’s filling up your eden, the larger objects might be of more interest) or bad (if you want to get a general

Re: Low-Overhead Heap Profiling

Do you mean “sample every X ms, say”? This is not impossible, but a little weird. Yes, you are right, this is weird and I don’t think is necessary for this type of profiling. Please ignore. Regards, Kirk

Re: Low-Overhead Heap Profiling

Thanks Jeremy - that helps - not such a big deal in terms of maintaining - so back to the bigger discussion. thanks, Karen On Jun 26, 2015, at 1:34 AM, Jeremy Manson wrote: Karen, I understand your concerns. For reference, this is the additional code in the x86 assembler. There are

Re: Low-Overhead Heap Profiling

Jeremy, Did I follow this correctly - that your approach modifies the compilers and interpreters and Tony's modifies the common allocation code? Given that the number of compilers and interpreters and interpreter platforms keeps expanding - I'd like to add a vote to have heap allocation

Re: Low-Overhead Heap Profiling

Bernd, I like the idea of buffering up the sampled objects in, some data structure. But I assume it’d have to be a per-thread data structure to avoid conention issues. So, we’ll also need a periodic task that collects all such data structures and makes them available (somehow) to whoever wants

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 1:28 PM, Tony Printezis tprinte...@twitter.com wrote: Hi Jeremy, Inline. On June 24, 2015 at 7:26:55 PM, Jeremy Manson (jeremyman...@google.com) wrote: On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis tprinte...@twitter.com wrote: Hi Jeremy, Please see

Re: Low-Overhead Heap Profiling

Karen, I understand your concerns. For reference, this is the additional code in the x86 assembler. There are very small stubs in C1 and the template interpreter to call out to this macro (forgive the gratuitous use of the string google - we sprinkle it around a bit because it makes it a little

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 1:55 PM, Tony Printezis tprinte...@twitter.com wrote: Bernd, I like the idea of buffering up the sampled objects in, some data structure. But I assume it’d have to be a per-thread data structure to avoid conention issues. So, we’ll also need a periodic task that

Re: Low-Overhead Heap Profiling

Hi Jeremy, Inline. On June 24, 2015 at 7:26:55 PM, Jeremy Manson (jeremyman...@google.com) wrote: On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis tprinte...@twitter.com wrote: Hi Jeremy, Please see inline. On June 23, 2015 at 7:22:13 PM, Jeremy Manson (jeremyman...@google.com) wrote: I

Re: Low-Overhead Heap Profiling

Hi Kirk, (long time!) See inline. On June 25, 2015 at 2:54:04 AM, Kirk Pepperdine (kirk.pepperd...@gmail.com) wrote: But, seriously, why didn’t you like my proposal? It can do anything your scheme can with fewer and simpler code changes. The only thing that it cannot do is to sample based

Re: Low-Overhead Heap Profiling

BTW, Could we get a reaction from the Oracle folks on this? Even though Jeremy and myself are proposing different implementation approaches, we both agree (and Jeremy please correct me on this) that having an allocation sampling mechanism that’s more flexible to what’s already in HotSpot (in

Re: Low-Overhead Heap Profiling

On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis tprinte...@twitter.com wrote: Hi Jeremy, Please see inline. On June 23, 2015 at 7:22:13 PM, Jeremy Manson (jeremyman...@google.com) wrote: I don't want the size of the TLAB, which is ergonomically adjusted, to be tied to the sampling rate.

Re: Low-Overhead Heap Profiling

Am Wed, 24 Jun 2015 16:26:35 -0700 schrieb Jeremy Manson jeremyman...@google.com: As for the other concern: my concern about *just* having the callback mechanism is that there is quite a lot you can't do from user code during an allocation, because of lack of access to JNI. Maybe I

Re: Low-Overhead Heap Profiling

Hi Jeremy, Please see inline. On June 23, 2015 at 7:22:13 PM, Jeremy Manson (jeremyman...@google.com) wrote: I don't want the size of the TLAB, which is ergonomically adjusted, to be tied to the sampling rate.  There is no reason to do that.  I want reasonable statistical sampling of the

Re: Low-Overhead Heap Profiling

ASGCT_CallTrace *trace; So it looks like this uses the AsyncGetTrace() infrastructure. Does your tool work on Windows and MacOS X? Dan On 6/22/15 10:58 PM, Jeremy Manson wrote: While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle. Any

Re: Low-Overhead Heap Profiling

I haven't tried! Another problem with our submitting things is that we can't really test on anything other than Linux. The reason we use ASGCT is that our modified version of ASGCT gathers native frames *and* Java frames, getting a mixed mode stack trace that crosses JNI boundaries. I haven't

Re: Low-Overhead Heap Profiling

If it is a blocker for this work, we can find a way to test on OS X and Windows. Jeremy On Tue, Jun 23, 2015 at 9:14 AM, Jeremy Manson jeremyman...@google.com wrote: I haven't tried! Another problem with our submitting things is that we can't really test on anything other than Linux. The

Re: Low-Overhead Heap Profiling

2015-06-23 19:01 GMT+02:00 Jeremy Manson jeremyman...@google.com: If it is a blocker for this work, we can find a way to test on OS X and Windows. Yeah, I think if this is going to be a general interface, we need to test on all the official platforms. Cheers, Mario Jeremy On Tue, Jun 23,

Re: Low-Overhead Heap Profiling

Hi Vladimir, The difference would be in the licensing. Kind regards, Kirk Pepperdine On Jun 23, 2015, at 7:31 AM, Vladimir Voskresensky vladimir.voskresen...@oracle.com wrote: Hello Jeremy, If this is sampling, not tracing, then how is it different from the low-overhead memory profiling

Re: Low-Overhead Heap Profiling

2015-06-23 6:58 GMT+02:00 Jeremy Manson jeremyman...@google.com: While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle. Any volunteers? It will also need a little polish to be available to the world. Open design questions for

Re: Low-Overhead Heap Profiling

Hi Jeremy, It will also need a little polish to be available to the world. Open design questions for upstreaming are things like: - Should the interval between samples be configurable? This could be helpful. - Should it *just* take a stack trace, or should the behavior be

Re: Low-Overhead Heap Profiling

Mario and Kirk - Random followup to the comments: Mario: Internally, we have both a callback mechanism (which is off by default) and a sampling mechanism, which is always on. We can certainly contribute both. The callback mechanism has a strict rule that you don't call JNI in it. The one

Re: Low-Overhead Heap Profiling

Jeremy (and all), I’m not on the serviceability list so I won’t include the messages so far. :-) Also CCing the hotspot GC list, in case they have some feedback on this. Could I suggest a (much) simpler but at least as powerful and flexible way to do this? (This is something we’ve been meaning

Re: Low-Overhead Heap Profiling

I don't want the size of the TLAB, which is ergonomically adjusted, to be tied to the sampling rate. There is no reason to do that. I want reasonable statistical sampling of the allocations. All this requires is a separate counter that is set to the next sampling interval, and decremented when

Low-Overhead Heap Profiling

Hey folks, (cc'ing Aleksey and John, because I mentioned this to them at the JVMLS last year, but I never followed up.) We have a patch at Google I've always wanted to contribute to OpenJDK, but I always figured it would be unwanted. I've recently been thinking that might not be as true,

Re: Low-Overhead Heap Profiling

I for one would love it. Cheers, Mario 2015-06-22 20:48 GMT+02:00 Jeremy Manson jeremyman...@google.com: Hey folks, (cc'ing Aleksey and John, because I mentioned this to them at the JVMLS last year, but I never followed up.) We have a patch at Google I've always wanted to contribute to

Re: Low-Overhead Heap Profiling

Hello Jeremy, If this is sampling, not tracing, then how is it different from the low-overhead memory profiling provided by JFR [1]. JFR samples per new TLAB allocation. It provides really very good picture and I haven't seen overhead more than 2%. Btw, JFR also does not have false positives

Re: Low-Overhead Heap Profiling

While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle. Any volunteers? It will also need a little polish to be available to the world. Open design questions for upstreaming are things like: - Should the interval between samples be