[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-gc-dev
Subject: Re: Low-Overhead Heap Profiling
From: Jeremy Manson <jeremymanson () google ! com>
Date: 2017-04-04 23:28:04
Message-ID: CAPYFHW38d6nGpW7OObfdLyuj2RvRcy_EygsVbzPMoXnTz3JJxQ () mail ! gmail ! com
[Download RAW message or body]
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@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@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
>>
>>
>>
>
[Attachment #3 (text/html)]
<div dir="ltr">Resurrecting ancient thread - this is now a draft JEP (<a \
href="http://openjdk.java.net/jeps/8171119">http://openjdk.java.net/jeps/8171119</a>) \
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.<div><br></div><div>Jeremy </div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 2:22 PM, \
Jeremy Manson <span dir="ltr"><<a href="mailto:jeremymanson@google.com" \
target="_blank">jeremymanson@google.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">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:<div><br></div><div>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.</div><div><br></div><div>2) I did envision a JVMTI interface. More in \
the JEP.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><span class="HOEnZb"><font \
color="#888888"><div><br></div><div>Jeremy</div></font></span><div><div \
class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 \
at 4:04 AM, Staffan Larsen <span dir="ltr"><<a \
href="mailto:staffan.larsen@oracle.com" \
target="_blank">staffan.larsen@oracle.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <br>
Sorry for being away for so long.<br>
<br>
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.<br> <br>
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.<br> <br>
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?<br> <br>
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.<br> <br>
Thanks,<br>
/Staffan<br>
<br>
<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic