JDK-8171119: Low-Overhead Heap Profiling

[serguei.spitsyn at oracle.com]

Added gc-hotspot-dev.

Are there any memory allocation benchmarks that we could run to make 
sure performance is Okay?

Thanks,
Serguei


On 4/30/18 11:19, JC Beyler wrote:
> 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
>>>
>>
>>
>>
>>