Re: AccessController speedup

["Scott Gilbertson" <scottg at mantatest dot com>]

From: "Gary Benson"
> Classpath's VMAccessController uses ThreadLocal objects to store per-
> thread state information.  Both Classpath and GCJ have a pure Java
> ThreadLocal implementation which results in a lot of extra GC activity
> with a security manager.  This commit changes VMAccessController to
> use an instance variable in Thread to store its state.  On my Tomcat
> benchmark this improves performace from 2400 to 2700 requests per
> second.
>
> Cheers,
> Gary

I'm getting a segmentation fault that could be related to the recent
unwinder changes.  I have the core dump and binary that generated the
backtrace below.  The problem happens with both static and dynamic
executables.

Is there any information I can provide (memory dumps or whatever) that would
help to determine what's happening?

Do you suppose "--disable-tls" or "--enable-sjlj-exceptions" has anything to
do with it?

 I'm on Linux version 2.6.8.1-10mdk, glibc2.3.4.
GCC configured with:
--prefix=/var/local/gcc/tip_20060627
--mandir=/var/local/gcc/man
--infodir=/var/local/gcc/info
--enable-shared
--enable-threads=posix
--disable-checking
--host=i386-redhat-linux
--enable-java-awt=xlib
--enable-libgcj
--enable-languages=c,c++,java
--with-system-zlib
--enable-__cxa_atexit
--disable-tls
--enable-sjlj-exceptions

Program terminated with signal 11, Segmentation fault.

#0  0x083627f8 in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:290
#1  0x0836282d in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:295
#2  0x0836282d in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:295
#3  0x0836282d in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:295
#4  0x0836282d in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:295
#5  0x0836282d in GC_clear_stack_inner (arg=0x83a000 "", limit=3219129200)
    at ../../../gcc/boehm-gc/misc.c:295
#6  0x08362895 in GC_clear_stack (arg=0x83a000 "")
    at ../../../gcc/boehm-gc/misc.c:341
#7  0x0835ed8d in GC_malloc_atomic (lb=4000)
    at ../../../gcc/boehm-gc/malloc.c:270
#8  0x080d4bd5 in _Jv_AllocBytes (size=4000)
    at ../../../gcc/libjava/boehm.cc:309
#9  0x08366ce1 in _Jv_StackTrace::UnwindTraceFn (context=0xbfe02858,
    state_ptr=0xbfe030b4) at ../../../gcc/libjava/stacktrace.cc:103
#10 0x080929e0 in _Unwind_Backtrace (
    trace=0x8366c04 <_Jv_StackTrace::UnwindTraceFn(_Unwind_Context*,
void*)>,
    trace_argument=0xbfe030b4) at unwind.inc:299
#11 0x08366b8e in _Jv_StackTrace::GetStackTrace ()
    at ../../../gcc/libjava/stacktrace.cc:165
#12 0x0836dea5 in java::lang::VMThrowable::fillInStackTrace ()
    at ../../../gcc/libjava/java/lang/natVMThrowable.cc:33
#13 0x08243220 in _ZN4java4lang9Throwable16fillInStackTraceEJPS1_v (
    this=0x4d30f0) at Throwable.java:498
#14 0x08242cc8 in java.lang.Throwable.Throwable(java.lang.String) (
    this=0x4d30f0, message=0x0) at Throwable.java:159
#15 0x08242ca3 in java.lang.Throwable.Throwable() (this=0x4d30f0)
    at Throwable.java:146
... (recursive) ...