JDK-8171119: Low-Overhead Heap Profiling
JC Beyler
jcbeyler at google.com
Thu Apr 26 22:40:41 UTC 2018
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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180426/c4809952/attachment.html>
More information about the serviceability-dev
mailing list