[Gc]: Re: Partially scanning a VM's call stack

[Boehm, Hans]

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.

Hans

> -----Original Message-----
> From: Ivan Maidanski
> Sent: Friday, August 28, 2009 10:05 AM
> To: gc at napali.hpl.hp.com
> Subject: Re[2]: [Gc]: Re: Partially scanning a VM's call stack
> 
> Hi!
> 
> "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 
> GC_new_proc, 
> > 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?
> 
> Bye.