Low-Overhead Heap Profiling

[Jeremy Manson]

Resurrecting ancient thread - this is now a draft JEP (
http://openjdk.java.net/jeps/8171119) with prototype.  JC on our team
posted to serviceability-dev with a link to the prototype, so those who are
interested should go and throw rotten tomatoes^W^Wlarge amounts of money.

Jeremy

On Tue, Aug 4, 2015 at 2:22 PM, 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170404/1bac1e23/attachment.htm>