Re: FYI: Faster AccessController stack decoder

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Gary Benson wrote:
 > > Tom Tromey wrote:
 > > 
 > > Indeed.  I have a couple of other things that might speed it up,
 > > but not by loads since the majority of the performance hit is in
 > > the unwinder.
 > 
 > Has anyone ever profiled the unwinder?

Me, lots of times.  It is one of the biggest performance losers in all
of gcj.  The time is dominated by two things: searching for the
appropriate unwinder data for a PC value, and decoding the bytecodes
that constitute the DWARF unwinder data.

 > That might be a fruitful thing to do.  I would seem that your
 > Tomcat benchmark is bound by the unwinder.  Any improvement in the
 > unwinder would result in a similar improvement to your benchmark.

Indeed.  I have given it quite a lot of thought, and there are
basically two possibilities: abandon the DWARF unwinder or accelerate
it by caching.  The latter technique is used by Valgrind, and we could
adapt the technique used there for use in libgcc.

However, in the case of the security manager there's no need to unwind
at all.  The paper in [1] describes a separate stack of security
contexts, and that would be reasonable to implement in libgcj.  I
suspect that it would be faster than anything we could do to
accelerate unwinding, and probably easier.

Andrew.

[1]  Implementing Protection Domains in the JavaTM Development Kit 1.2
Li Gong and Roland Schemers