Low-Overhead Heap Profiling

[JC Beyler]

Hi all,

To move the discussion forward, with Chuck Rasbold's help to make a webrev,
we pushed this:
http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/index.html
415 lines changed: 399 ins; 13 del; 3 mod; 51122 unchg

This is not a final change that does the whole proposition from the JBS
entry: https://bugs.openjdk.java.net/browse/JDK-8177374; what it does show
is parts of the implementation that is proposed and hopefully can start the
conversation going as I work through the details.

For example, the changes to C2 are done here for the allocations:
http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/src/share/vm/opto/macro.cpp.patch

Hopefully this all makes sense and thank you for all your future comments!
Jc


On Tue, Dec 13, 2016 at 1:11 PM, JC Beyler <jcbeyler at google.com> wrote:

> Hello all,
>
> This is a follow-up from Jeremy's initial email from last year:
> http://mail.openjdk.java.net/pipermail/serviceability-dev/
> 2015-June/017543.html
>
> I've gone ahead and started working on preparing this and Jeremy and I
> went down the route of actually writing it up in JEP form:
> https://bugs.openjdk.java.net/browse/JDK-8171119
>
> I think original conversation that happened last year in that thread still
> holds true:
>
>  - We have a patch at Google that we think others might be interested in
>     - It provides a means to understand where the allocation hotspots are
> at a very low overhead
>     - Since it is at a low overhead, we can leave it on by default
>
> So I come to the mailing list with Jeremy's initial question:
> "I thought I would ask if there is any interest / if I should write a JEP
> / if I should just forget it."
>
> A year ago, it seemed some thought it was a good idea, is this still true?
>
> Thanks,
> Jc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170404/47e00cf5/attachment-0001.html>