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