Low-Overhead Heap Profiling

Kees Jan Koster kjkoster at gmail.com
Wed Aug 12 11:28:10 UTC 2015


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 <jeremymanson at google.com> 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 responses:
> 
> 1) It was a fair bit of work to do it, mostly because it was the first time I had tinkered with c2.  This was 5 years ago.  Most of the work since then has been dealing with merge conflicts.
> 
> 2) I did envision a JVMTI interface.  More in the JEP.
> 
> 3) We have some internal tests, but obviously, we'd have to figure out how to externalize them.  For native code, it's much easier only to have to worry about building and running on Linux.  Presumably, there's already code in there for JVMTI.
> 
> I'll try to get a JEP going for real, although it might not happen in the next week or so, because I'm moving next week (+the JVMLS).
> 
> Jeremy
> 
> On Tue, Aug 4, 2015 at 4:04 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 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 should collect better information than what that event does.
> 
> I like the approach of instrumenting the interpreter and compiler to do the sampling. I had thought it would be a lot of work to do it and was reluctant to go down that path. If the work is already done and Jeremy has maintained it for a few years without great problems, I think we should look at bringing it in. I am not worried about the overhead of a decrement and a compare in the allocation path, but of course we should benchmark that.
> 
> It wasn’t clear to me from the discussion how (or if) this was being exposed to end users. Was the proposal to just have the native entry points in the VM and have these be used by various agents? Would this be part of JVMTI?
> 
> I think a draft JEP would be the logical next step and make it easier for us all to discuss what exactly the proposal should contain. Also, let’s not forget the need for tests for the feature.
> 
> Thanks,
> /Staffan
> 
> 
> 


--
Kees Jan

http://java-monitor.com/
kjkoster at kjkoster.org
+31651838192

The secret of success lies in the stability of the goal. -- Benjamin Disraeli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150812/8adf0387/signature.asc>


More information about the hotspot-gc-dev mailing list