JDK-8171119: Low-Overhead Heap Profiling

[JC Beyler]

Hi all,

Did anybody have some time to look at this? Any insight would be
appreciated!

Thanks!
Jc

On Thu, Apr 26, 2018 at 3:40 PM JC Beyler <jcbeyler at google.com> wrote:

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