Re: [Gc]: Re: Partially scanning a VM's call stack
ivmai at mail.ru
Tue Sep 1 00:12:21 PDT 2009
"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.
> > 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?
More information about the Gc