AccessController speedup

Tue Aug 22 15:54:00 GMT 2006

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) ...