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

Boehm, Hans hans.boehm at hp.com
Wed Aug 19 19:01:33 PDT 2009

> From:  Ludovic Courtès
> ludo at gnu.org (Ludovic Courtès) writes:
> > Juan Jose Garcia-Ripoll
> > <juanjose.garciaripoll at googlemail.com> writes:
> >
> >> 2009/8/19 Ivan Maidanski <ivmai at mail.ru>:
> >>>> This looks like the easiest solution.  OTOH `GC_gcj_malloc ()' 
> >>>> appears to be undocumented, so I'd rather go for 
> GC_new_kind + GC_MAKE_PROC.
> >>>
> >>> It's public (exported from gc_gcj.h). It's used in 
> GCC/GCJ (and Mono AFAIK) projects.
> >>
> >> The fact that something is exported in a header and 
> commented in the 
> >> mailing list does not make it look like a stable feature of the 
> >> garbage collector. In particular, I can barely gather how those 
> >> descriptors work from your emails.
> >
> > Agreed.  The very name of the function makes it sound like 
> a warning 
> > to non-GCJ developers.
> ... and the example at
> https://permalink.gmane.org/gmane.comp.programming.garbage-coll
> isn't reassuring either:
>   GC_init_gcj_malloc(5, 0); /* magical 5 for mp=0 (as used in 
> other projects on the web) */
> Ludo'.
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 marc proc at least breaks the debugging interface,
and is not recommended.  Any small integer will probably work for the

If the stacks can be dynamically allocated, I would personally
address this problem directly with a custom mark proc.  The other
ideas suggested here can probably also be made to work.  Dynamically
adjusting the descriptor may not work with incremental collection;
I'd worry about subtle races with objects already on the mark stack.
Certainly the collector code was written on the assumption that mark
descriptors are static, and anything more dynamic is captured by
mark procedures.

I attempted to enable Mediawiki on the sourceforge project.  It looks
like that takes a little while to happen.


More information about the Gc mailing list