Breakpoint Performance (JVMTI)

Nicolas Michael mail at nmichael.de
Thu Apr 9 06:42:00 PDT 2009


Christian, Paul,

thanks a lot for your replies!

> On Thu, 2009-04-09 at 05:40 +0000, Nicolas Michael wrote:
> > process is becoming a lot more expensive. Sun Studio profiling shows that we
> > spend almost 30% of the CPU time in handling breakpoints and related effort
> > (e.g. running interpreted instead of JIT-compiled code for this class's
> > methods).
> 
> I am taking care of CR 4836252, which should fix the interpreted method
> problem.

Oh, that's great!
For which Hotspot release do you think this will be realized? (Just very
roughly, I'm of course not asking for a definite answer... just to get an idea,
since this CR was opened in 2003.)

> > It seems, orig_bytecode_at(int) is iterating linearly over a list of all
> > breakpoints of this class (in our case: about 1,000) to find the matching
> > breakpoint:
> > 
> > Bytecodes::Code methodOopDesc::orig_bytecode_at(int bci) {
> >   BreakpointInfo* bp = instanceKlass::cast(method_holder())->breakpoints();
> >   for (; bp != NULL; bp = bp->next()) {
> >     if (bp->match(this, bci)) {
> >       return bp->orig_bytecode();
> >     }
> >   }
> >   ShouldNotReachHere();
> >   return Bytecodes::_shouldnotreachhere;
> > }
> 
> The code is very simple and definitely could be optimized.  I'm just not
> sure if it's worth.

Ok, I see. ;-)

@Paul: Thanks for pointing us to btrace! This seems to be an interesting tool.
I'll have a look at it.

Thanks,
Nick.




More information about the hotspot-compiler-dev mailing list