[Gc]: Re: Partially scanning a VM's call stack
hans.boehm at hp.com
Mon Aug 31 15:53:28 PDT 2009
The way this interface is currently set up, you need to supply a mark proc for objects allocated through the debugging interface.
The mark proc needs to at least be capable of handling an object allocated with GC_debug_gcj_malloc. If it is given such an argument, the env parameter will be one.
In this case, you need to skip over the debug header in the object (GC_USR_PTR_FROM_BASE).
For anything like the intended use, the mark proc will typically also handle larger objects with nontrivial layout, since that information doesn't fit into a bitmap descriptor.
If you don't otherwise need the mark proc, and don't use GC_debug_gcj_malloc, you can probably get away with just passing a mark proc that prints an error message if it is ever called. Passing zero as the mark proc seems to be a suboptimal way to do something similar, but errors may be really hard to debug. And the value of zero also makes the GC_mark_procs entry look unused, which is probably also unfortunate.
There is a sample use in the gcc code at https://gcc.gnu.org/viewcvs/trunk/libjava/boehm.cc?revision=138078&view=markup
If this turns into a major issue, the code here could be more friendly and default to a mark proc that conservatively scans the whole object. I think the use cases for that are quite far removed from the original motivation.
> -----Original Message-----
> From: Ivan Maidanski
> Sent: Friday, August 28, 2009 10:05 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc]: Re: Partially scanning a VM's call stack
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > > ...
> > > GC_init_gcj_malloc(5, 0); /* magical 5 for mp=0 (as
> used in other
> > > projects on the web) */
> > This is definitely intended to be part of the public interface.
> > The GC_init_gcj_malloc interface could be a bit better documented.
> > The technical problem is that it should logically rely in
> > but can't, since for something like JVM or Mono, the
> compiler has to
> > generate mark descriptors, and hence needs to know the mark
> proc index
> > in advance. I'll improve the comment a bit.
> > (Passing a null mark proc at least breaks the debugging
> interface, and
> > is not recommended. Any small integer will probably work for the
> > index.)
> I don't use GC_DS_PROC and I don't want to pass a fake proc
> to it (but I do want to stay within the GCJ API). It's
> unclear (to me) how should GC_gcj_debug_kind be correctly
> initialized if the client doesn't use mp at all (but may
> happen to call GC_debug_gcj_malloc()). Could you point me?
More information about the Gc