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

Ivan Maidanski ivmai at mail.ru
Tue Sep 1 00:12:21 PDT 2009


Hi!

"Boehm, Hans" <hans.boehm at hp.com> wrote:
> 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. 

I use GC_GCJ_MALLOC() (leaving GC_DEBUG to be defined if debugging), and I'd prefer the GC itself hides the differences between GC_debug_... and normal GC_... functions (at least in respect to mark procs), and I'd prefer not to bother with mark procs in an application which doesn't use GC_DS_PROC. (And I'd prefer at least some macro defining some recommended value for mp_index to use when calling GC_init_gcj_malloc() (or just another initialization no-arg func) for the this case.)

Do you mind such changes in GC? (In fact, it's unclear to me for now how to do it - the quick temporary change is to leave GC_gcj_debug_kind uninitialized if mp==0 and abort in GC_debug_gcj_malloc if GC_gcj_debug_kind==0, or alternatively establish a mark proc that prints an error message.)

> 
> There is a sample use in the gcc code at  http://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
> 
> > 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.


More information about the Gc mailing list