[Gc] RE: Abuse of collector...

Talbot, George Gtalbot at locuspharma.com
Mon May 18 09:00:21 PDT 2009

Wow.  That's really impressive.  Somehow it seems better if the compiler could do that...I'd be afraid of getting it wrong.

George T. Talbot
<gtalbot at locuspharma.com>

From: gc-bounces at napali.hpl.hp.com [gc-bounces at napali.hpl.hp.com] On Behalf Of Andrew Haley [aph at redhat.com]
Sent: Monday, May 18, 2009 11:20 AM
To: Talbot, George
Cc: gc at napali.hpl.hp.com; 'Ivan Maidanski'
Subject: Re: [Gc] RE: Abuse of collector...

Talbot, George wrote:
>> -----Original Message-----
>> From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com]
>> On Behalf Of Ivan Maidanski
>> ...
>> Hmm... I observe that GC_ENABLE_INCREMENTAL is not working on Linux amd64
>> (unlike linux32 or SunOS on amd64, or Win32 where the printed number of
>> collection is smaller by somewhat 1/4...1/2 in the inc mode).
>> Further investigation is needed for Linux64...
> Anything that I could help with that would help an expert diagnose what's going on?
>> Also, You could try GCJ-style allocations for partially ptr-containing
>> objects (I think only length-based descriptors could be potentially
>> increase collection speed for 64-bit arch where the probability of false
>> marking of an unreachable object is very low), but it's typically not an
>> easy task as you should reorder structs fields and add vtable ptr.
> Would you have any example code?  This is not totally impractical for my main data structures...

gcj uses a bitmap descriptor to map pointers.  See _Jv_BuildGCDescr in
http://gcc.gnu.org/svn/gcc/trunk/libjava/boehm.cc.  If our object is too
large to use a bitmap, the gc calls _Jv_MarkObj.

Gc mailing list
Gc at linux.hpl.hp.com

More information about the Gc mailing list