Additional path for 5.0 jvm crash on exhaustion of CodeBuffer

Solaris 8 java 1.5.0_06 with options:
-Xmn1152m -Xms2944m -Xmx2944m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxPermSize=384m

----------------- t@16 -----------------
0xff3691f0 __sigprocmask + 0x8
0xff35dd0c _sigon + 0xd0
0xff360d4c _thrp_kill + 0xf8
0xff24bce0 raise + 0x40
0xff235984 abort + 0x100
0xfe264724 void os::abort(int) + 0x58
0xfe2f08f0 void VMError::report_and_die() + 0xc84
0xfe035b24 void report_fatal_vararg(const char*,int,const char*,...) + 0x44
0xfddb4b70 CodeBuffer::CodeBuffer #Nvariant 1(int,int,int,int,int,int,BufferBlob*,relocInfo*,RelocateBuffer*,int,OopRecorder*,const char*,int,int) + 0xbc
0xfde1b140 void CodeBuffer::resize(int,int,int,int) + 0x94
0xfde26de8 void Compile::Fill_buffer() + 0xc64
0xfde24574 void Compile::Output() + 0x9f0
0xfde1a408 void Compile::Code_Gen() + 0x384
0xfde8276c Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,int) + 0xc14
0xfde786f8 void C2Compiler::compile_method(ciEnv*,ciMethod*,int) + 0xb0
0xfde793b4 void CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x4cc
0xfdf35f20 void CompileBroker::compiler_thread_loop() + 0x44c
0xfdede29c void JavaThread::run() + 0x1d8
0xfe264240 void*_start(void*) + 0x208
0xff36b01c _thread_start + 0x40

(dbx) frame 9
0xfe035b24: report_fatal_vararg+0x0044: call report_and_die ! 0xfe2efc6c
(dbx) x 0xfe336047/s
0xfe336047: __RTTI__1nNExceptionBlob_+0x03a7: "/BUILD_AREA/jdk1.5.0_06/hotspot/src/share/vm/asm/codeBuffer.cpp"
(dbx) print 0x60
96
(dbx) x 0xfe336087/s
0xfe336087: __RTTI__1nNExceptionBlob_+0x03e7: "CodeCache: no room for %s"
(dbx) x 0xfe336030/s
0xfe336030: __RTTI__1nNExceptionBlob_+0x0390: "CodeBuffer constructor"

Same as
http://cheesypoof.uk:8080/Saucer/ErrorID?id=434F44452255464645520E4350500060
Error ID 434F44452255464645520E4350500060 = codeBuffer.cpp, line 96

which is http://cheesypoof.uk.sun.com/lxr2/source/ws/hotspot/src/share/vm/asm/codeBuffer.cpp?v=Java_1.5.0_06#096

I can also see that
Thread t@52: is deep and all compiled
Thread t@24: is deep and all compiled
Thread t@21: is deep and all compiled

Heap
par new generation total 1178560K, used 1065004K [0x28000000, 0x70000000, 0x70000000)
 eden space 1177472K, 90% used [0x28000000, 0x6900b128, 0x6fde0000)
 from space 1088K, 0% used [0x6fde0000, 0x6fde0000, 0x6fef0000)
 to space 1088K, 0% used [0x6fef0000, 0x6fef0000, 0x70000000)
concurrent mark-sweep generation total 1835008K, used 546506K [0x70000000, 0xe0000000, 0xe0000000)
concurrent-mark-sweep perm gen total 126464K, used 126206K [0xe0000000, 0xe7b80000, 0xf8000000)

According to 4925292 and looking at perm space I would suggest in the meantime to use:

-XX:CodeCacheMinimumFreeSpace=2M -XX:+ReservedCodeCacheSize=64M (defaults are free 512k and size 32m)
-XX:PermSize=128m -XX:MaxPermSize=384m
-XX:+CMSPermGenSweepingEnabled

but this is 1.5.0_06 so it shouldn't happen any more a crash for a small CodeCache ? Is it a regression of 4925292 ?
(Obviously it should be better to use /usr/lib/lwp/libthread.so.1 always )

More info in /net/cores.central/cores/10916493/sunup10916493/coreinfo_83a38a37_20060925