Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)

[Per Bothner]

Cedric Berger <cedric@wireless-networks.com> writes:

> What would be ideal, I guess, is a mixed system: using whatever
> collector is the faster most of the time, but if there is an
> Out-Of-Heap conditions, stopping everybody and doing a complete,
> slow, compacting & precise GC. I've look at the litterature, and
> freeware stuff, but never found such a system. Most compacting
> GC described are copying GC, and loosing half the memory is 
> usually not an option in embedded systems. especially for system
> without MMUs.

You may not have found a "complete, slow, compacting & precise GC"
in the literature because it is not publishable, at least not now.
If you go back far enough (i.e. the 60-ies) maybe you'd find something.
The non-obvious issues about such a GC include being careful to
only require a finite amount of stack space, which might involve
pointer "swizzling".

I assume you've followed the links from http://iecc.com/gclist/GC-faq.html .

The other problem is how to handle pointers from the stack.
A easy though slow method is to translate:

void foo (Object x)
{
  Object y = ...;
  String z = ...;
}

to

void foo (jobject x)
{
  struct {
     jobject x;
     jobject y;
     jstring z;
  } p;
  _Jv_RegisterPointers(&p, sizeof(*p));
  try {
    p.x = x;
    p.y = ...;
    p.z = ...;
  } finally { _Jv_UnRegisterPointers(&p, sizeof(*p))' }
}

_Jv_RegisterPointers add the pointers to the root set (after zeroing
them); _Jv_UnRegisterPointers removes them from the root set.

You can make things simpler you just calling:
_Jv_RegisterPointers(&x, 1);
_Jv_RegisterPointers(&y, 1);
_Jv_RegisterPointers(&z, 1);
then you don't need to rewrite x to p.x etc,
but you have to call _Jv_RegisterPointers once for each pointer.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/