Enhancement Request

Thu Jan 2 19:02:00 GMT 2003

Some clarifications (I was out for a while):
As Jeff pointed out, I don't think there's anything particularly strange about the gc configuration used by gcj. It's built with GC_GCJ_SUPPORT, but that just adds code; it doesn't change the behavior of the rest of the interface. (And I would hope that Portable.NET could use the same object descriptor support in any case.)
I did update the version of autoconf/automake used in the most recent upstream gc release, with some help from others. (This was mostly motivated by my inability to keep it working with the old versions.)
My guess is that the most serious potential issue with configuration conflicts is during runtime configuration. _Jv_InitGC does
 GC_all_interior_pointers = 0;
...
 GC_java_finalization = 1;
I'm not sure whether the first one is safe for Portable.NET. It implies that all pointers stored in the heap and in static data areas must either point to the beginning of objects, or to fixed registered offsets within objects. (I believe libgcj normally registers no such offsets.) GC_all_interior_pointers = 1 is safe for libgcj, but may cause extra memory retention.
GC_java_finalization = 1 is needed whenever unordered finalization needs to be supported. Unfortunately that's true for both Java and .NET. It just slows things down a tiny bit for other code.
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Wednesday, January 01, 2003 7:15 PM
> To: Glenn Chambers
> Cc: tromey@redhat.com; java@gcc.gnu.org
> Subject: Re: Enhancement Request
>>> On 2002年12月31日, Glenn Chambers wrote:
> > My problem with this strategy is that I find it hard to see 
> how linking
> > two distinct versions of 'libgc' will be able to work. 
> Even assuming the
> > code issues work out, there's still the fact that there 
> will be two gc'd
> > memory pools running in parallel, resulting in memory 
> wastage. There's
> > also the mildly interesting question of whether GC-A will 
> scan GC-B's
> > pool looking for live pointers into GC-A's pool of objects.
>> Can you simply link your Portable.NET application to 
> libgcj.so instead of
> libgc.a/libffi.a?
>