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