JDK-8171119: Low-Overhead Heap Profiling

[JC Beyler]

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>