[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: JDK-8171119: Low-Overhead Heap Profiling
From: JC Beyler <jcbeyler () google ! com>
Date: 2018-04-26 22:40:41
Message-ID: CAF9BGBw=-xXT_HdCOtZF33paCL+N3GcrYpNwvjDSV+PO=1voJg () mail ! gmail ! com
[Download RAW message or body]
Hi all,
Sorry for the double post but I was suggested to send this to the
runtime-dev mailing list but force of habit made me send it to
serviceability first.
If anyone on the runtime-dev could look at this, it would be
greatly appreciated.
Background:
- I am trying to add a sampling system that samples allocations and some
allocation points need to protect oops that are on the stack
- What would be the best way and not risk adding any overhead?
- One way was adding Handles like what is done below, what is the
runtime-dev mailing list's opinion on this?
Thanks for your help!
Jc
On Thu, Apr 26, 2018 at 11:02 AM JC Beyler <jcbeyler@google.com> wrote:
> Hi all,
>
> A question came up between myself and Serguei about how to protect the
> newly allocated oop when the collector does the callback. We decided it
> might be best to ask the mailing list for help/guidance/opinion?
>
> Consider the changes done in this file for example:
>
> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.16/src/hotspot/share/gc/shared/collectedHeap.inline.hpp.udiff.html
>
> For example, for obj_allocate, the change becomes:
> oop CollectedHeap::obj_allocate(Klass* klass, int size, TRAPS) {
> debug_only(check_for_valid_allocation_state());
> assert(!Universe::heap()->is_gc_active(), "Allocation during gc not
> allowed");
> assert(size >= 0, "int won't convert to size_t");
> +
> + HandleMark hm(THREAD);
> + Handle result;
> + {
> + JvmtiSampledObjectAllocEventCollector collector;
> HeapWord* obj = common_mem_allocate_init(klass, size, CHECK_NULL);
> post_allocation_setup_obj(klass, obj, size);
> NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj, size));
> - return (oop)obj;
> + result = Handle(THREAD, (oop) obj);
> + }
> + return result();
> }
>
> The question is: does anyone see an issue here in terms of performance or
> something we missed? When I measured it via the Dacapo run, I saw no
> performance degradation but I wanted to double check with you all if this
> would become a big no no for the final webrev?
>
> Were other benchmarks show that there is no overhead incurred, would this
> be ok?
>
> Thanks for your help,
> Jc
>
[Attachment #3 (text/html)]
<div dir="ltr">Hi all,<br><div><br></div><div>Sorry for the double post but I was \
suggested to send this to the runtime-dev mailing list but force of habit made me \
send it to serviceability first.</div><div><br></div><div>If anyone on the \
runtime-dev could look at this, it would be greatly appreciated. \
</div><div><br></div><div>Background:</div><div> - I am trying to add a sampling \
system that samples allocations and some allocation points need to protect oops that \
are on the stack</div><div> - What would be the best way and not risk adding any \
overhead?</div><div> - One way was adding Handles like what is done below, what is \
the runtime-dev mailing list's opinion on this?</div><div><br></div><div>Thanks \
for your help!<br></div><div>Jc</div><br><div class="gmail_quote"><div dir="ltr">On \
Thu, Apr 26, 2018 at 11:02 AM JC Beyler <<a \
href="mailto:jcbeyler@google.com">jcbeyler@google.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi \
all,<br><div><br></div><div>A question came up between myself and Serguei about how \
to protect the newly allocated oop when the collector does the callback. We decided \
it might be best to ask the mailing list for \
help/guidance/opinion?</div><div><br></div><div> Consider the changes done in this \
file for example:</div><div><a \
href="http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.16/src/hotspot/share/gc/shared/collectedHeap.inline.hpp.udiff.html" \
target="_blank">http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.16/src/hotspot \
/share/gc/shared/collectedHeap.inline.hpp.udiff.html</a><br></div><div><br></div><div>For \
example, for obj_allocate, the change becomes:</div><div><div> oop \
CollectedHeap::obj_allocate(Klass* klass, int size, TRAPS) {</div><div> \
debug_only(check_for_valid_allocation_state());</div><div> \
assert(!Universe::heap()->is_gc_active(), "Allocation during gc not \
allowed");</div><div> assert(size >= 0, "int won't convert to \
size_t");</div><div>+</div><div>+ HandleMark hm(THREAD);</div><div>+ Handle \
result;</div><div>+ {</div><div>+ JvmtiSampledObjectAllocEventCollector \
collector;</div><div> HeapWord* obj = common_mem_allocate_init(klass, size, \
CHECK_NULL);</div><div> post_allocation_setup_obj(klass, obj, size);</div><div> \
NOT_PRODUCT(Universe::heap()->check_for_bad_heap_word_value(obj, \
size));</div><div>- return (oop)obj;</div><div>+ result = Handle(THREAD, (oop) \
obj);</div><div>+ }</div><div>+ return result();</div><div> \
}</div></div><div><br></div><div>The question is: does anyone see an issue here in \
terms of performance or something we missed? When I measured it via the Dacapo run, I \
saw no performance degradation but I wanted to double check with you all if this \
would become a big no no for the final webrev?</div><div><br></div><div>Were other \
benchmarks show that there is no overhead incurred, would this be \
ok?</div><div><br></div><div>Thanks for your \
help,</div><div>Jc</div></div></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> \
</blockquote></div></blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic