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: 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/ T

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 StackT

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 Robbi

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 still

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 integr

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: http://cr.openjdk.java.net/~rasbold/8171

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:   - http://cr.openjdk.java.net/~ras

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 only

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 src/hotspot/shar

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: http://cr.openjdk.java.net/~

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 :) Ne

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: > > http://cr.openjdk.java.net/~rasbold/8171119/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 my_fu

Re: Low-Overhead Heap Profiling

Hi, On 06/28/2017 12:04 AM, JC Beyler wrote: Dear Thomas et al, Here is the newest webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/ You have some more bits to in there but generally this looks good and really nice with more tests. I'll do and deep dive and re-test this when I g

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 implementin

Re: Low-Overhead Heap Profiling

One more comment on the JVMTI spec update (jvmti.xml). In the Heap Monitoring section new typedefs are defined: Call Frame typedef struct { jint bci; jmethodID method_id; } jvmtiCallFrame; Stack Trace typ

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 occasionally

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 optional

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 ja

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: Dea

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 StackObj

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: >> http://cr.openjdk.java.net/~rasbold/8171119/webrev.02/ < >> ht

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 yo

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: http://cr.openjd

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 s

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 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 23:22, Jer

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 wrote: > > Thanks, Staffan. I've been tinkering with a draft JEP, but it has been going > slowly because of other craziness in my life. Some re

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 and

Re: Low-Overhead Heap Profiling

> > > > On Thu, Jun 25, 2015 at 2:23 PM, Tony Printezis > 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 someone else at

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 e

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

> > 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

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

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

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

On Thu, Jun 25, 2015 at 1:55 PM, Tony Printezis 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 collects > all such dat

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 littl

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 1:28 PM, Tony Printezis 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 > wrote: > >> Hi Jeremy, >> >> Please see inline. >> >> On June 23, 2015 a

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 par

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 on

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

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 profili

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  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 th

Re: Low-Overhead Heap Profiling

> > 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 on object count (i.e., every 100 objects) instead of > based on object size (i.e., every 1MB of allocations). But

Re: Low-Overhead Heap Profiling

Am Wed, 24 Jun 2015 16:26:35 -0700 schrieb Jeremy Manson : > > 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 missed somethin

Re: Low-Overhead Heap Profiling

On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis 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. There is no

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 alloc

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 a

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

2015-06-23 19:01 GMT+02:00 Jeremy Manson : > 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, 2015 at 9:14 AM, Jer

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 wrote: > 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 i

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 ch

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

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 thing

Re: Low-Overhead Heap Profiling

2015-06-23 6:58 GMT+02:00 Jeremy Manson : > 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:

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 > c

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 wrote: > Hello Jeremy, > > If this is sampling, not tracing, then how is it different from the > low-overhead memory profiling provided by JFR [1]. > JFR s

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

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 configura

Re: Low-Overhead Heap Profiling

I for one would love it. Cheers, Mario 2015-06-22 20:48 GMT+02:00 Jeremy Manson : > 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 > alwa