Low-Overhead Heap Profiling

[Jeremy Manson]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150804/f9d9e072/attachment.htm>