[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: JDK-8171119: Low-Overhead Heap Profiling
From:       "serguei.spitsyn () oracle ! com" <serguei ! spitsyn () oracle ! com>
Date:       2018-04-30 18:28:04
Message-ID: 7d66cf99-a213-c587-4082-361e370137b4 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]