[kaffe] (Maybe Bug Report): kaffe-1.1.5: Garbage collector: threadData.jvmpiData not scanned for pointers
guilhem at kaffe.org
Fri Jun 24 09:55:27 PDT 2005
I am not a JVMPI expert but SetThreadLocalStorage is only there to
record that some pointer is affected to some thread. I am not sure this
must be walked by the GC as this may be a "weak" reference. The
documentation on sun's site is not clear on that point and would require
further testing to be sure of the semantic. By the way, it is not
advised generally to mark an unknown object. Marking an unknown value
can lead to crash (as when you mark you generally assume the value you
give is a real heap pointer). In kaffe you will see there is only one
place where you make "random" marking: the GC itself. And this is only
after having checked we have a real heap pointer.
Any JVMPI user around ?
On Fri, 2005-06-24 at 17:31 +0400, Alexander Petrossian wrote:
> jvmpiSetThreadLocalStorage puts a pointer to local storage instances there:
> KTHREAD(get_data)(jt)->jvmpiData = ptr;
> but that field:
> is not scanned for pointers neither here
> liveThreadWalker [gc-refs.c]
> which only looks into
> nor anywhere else.
> the letters "jvmpiData" only occur in 3 places in source distribution:
> 431:jvmpi_kaffe.c jvmpiGetThreadLocalStorage
> 655:jvmpi_kaffe.c jvmpiSetThreadLocalStorage
> 25:threadData.h declaration
> this looks like a but to me, since if that storage would hold a last pointer to an object,
> that object will be reclaimed during garbage collect.
> test case for that should be obvious.
> I myself is not a java developer, I even have no kaffe binaries, so I can't run it.
> In case this is NOT a bug, please provide a short explanation to "how that can work".
> Alexander Petrossian, Moscow, Russia.
> kaffe mailing list
> kaffe at kaffe.org
More information about the kaffe