Re: Patch: FYI: java.lang.ref.*

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Tom Tromey wrote:

>This patch implements java.lang.ref.*.
>I'm checking it in.
>

Very cool! I actually started to implement java.lang.ref a long time 
ago, but never got it finished. My attempt was mostly inside boehm-gc, 
and it ended up looking pretty messy. I definately think this approach 
looks better.

>One known flaw is that the existing implementation always reclaims
>Soft references.  It would be better to do this only when memory is
>low.  I think this can be changed without affecting anything outside
>boehm.cc.
>

Maybe this should be called _Jv_GCShouldReclaimSoftReference? I guess we 
need a way to ask the GC if it is approaching its max heap size (and a 
way to set the max heap size from libjava?) to implement this properly. 
Wouldn't false actually be a better default for now, since SoftReference 
is supposed to be "only slightly weaker" than a real reference?

Oh... and btw it seems to crash for me ;-)

[Switching to Thread 1024 (LWP 1462)]
0x401c4780 in finalize_referred_to_object(java::lang::Object*) 
(obj=0x80a9cc0)
    at ../../../libjava/java/lang/ref/natReference.cc:257
257                   ref->enqueue ();
Current language:  auto; currently c++
(gdb) bt
#0  0x401c4780 in finalize_referred_to_object(java::lang::Object*) (
    obj=0x80a9cc0) at ../../../libjava/java/lang/ref/natReference.cc:257
#1  0x4030b8f5 in call_finalizer(void*, void*) (obj=0x80a9cc0,
    client_data=0x401c460a) at ../../../libjava/boehm.cc:392
#2  0x404d5652 in GC_invoke_finalizers () at 
../../../boehm-gc/finalize.c:781
#3  0x404d56f5 in GC_notify_or_invoke_finalizers ()
    at ../../../boehm-gc/finalize.c:803
#4  0x404d2085 in GC_try_to_collect (stop_func=0x404d12b0 
<GC_never_stop_func>)
    at ../../../boehm-gc/alloc.c:708
#5  0x404d20d7 in GC_gcollect () at ../../../boehm-gc/alloc.c:713
#6  0x4030b98f in _Jv_RunGC() () at ../../../libjava/boehm.cc:417
#7  0x401be78f in java::lang::Runtime::gc() (this=0x80a9fb0)
    at ../../../libjava/java/lang/natRuntime.cc:117
#8  0x401da1b7 in java.lang.System.gc() ()
    at ../../../libjava/java/lang/System.java:129
#9  0x08051131 in NumericSortTest::freeTestData() (this=0x80de4b0)
    at ./NumericSortTest.java:320
#10 0x08051145 in NumericSortTest::cleanup() (this=0x80de4b0)
    at ./NumericSortTest.java:335
#11 0x080509ca in NumericSortTest::dotest() (this=0x80de4b0)
    at ./NumericSortTest.java:208
#12 0x080612a0 in BmarkTest::benchWithConfidence() (this=0x80de4b0)
    at ./BmarkTest.java:123
#13 0x0804acf0 in jBYTEmark::main(JArray<java::lang::String*>*) (
    args=0x8090fe0) at ./jBYTEmark.java:167
#14 0x401b495f in gnu::gcj::runtime::FirstThread::call_main() 
(this=0x80b0fc0)
    at ../../../libjava/gnu/gcj/runtime/natFirstThread.cc:46
#15 0x402473f7 in gnu.gcj.runtime.FirstThread.run() (this=0x80b0fc0)
    at ../../../libjava/gnu/gcj/runtime/FirstThread.java:54
#16 0x401c37df in _Jv_ThreadRun(java::lang::Thread*) (thread=0x80b0fc0)
    at ../../../libjava/java/lang/natThread.cc:285
#17 0x4019351e in _Jv_RunMain(java::lang::Class*, char const*, int, char 
const**, bool) (klass=0x806af00, name=0x0, argc=1, argv=0xbffff9d4, 
is_jar=false)
    at ../../../libjava/prims.cc:951
#18 0x4019358b in JvRunMain (klass=0x806af00, argc=1, argv=0xbffff9d4)
    at ../../../libjava/prims.cc:961
#19 0x0804a154 in main (argc=1, argv=0xbffff9d4) at /tmp/ccnorzMqmain.i:0
#20 0x4053a177 in __libc_start_main (main=0x804a120 <main>, argc=1,
    ubp_av=0xbffff9d4, init=0x8049bb4 <_init>, fini=0x8065798 <_fini>,
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff9cc)
    at ../sysdeps/generic/libc-start.c:129

This is with the jBYTEmark benchmark, 
http://waitaki.otago.ac.nz/~bryce/gcj/jbytemark-0.9+.tar.gz

jBYTEmark doesn't register any finalizers or use the ref API, so its a 
bit weird. I guess maybe some other part of the runtime is causing this 
to be invoked.

(gdb) p ref
$1 = (struct Reference *) 0x4044ac98

Which looks like a function address? It sure aint a java.lang.Reference. 
Unless gdb is playing tricks on me...

regards

Bryce.