[Gc] RE: Abuse of collector...

Andrew Haley aph at redhat.com
Mon May 18 09:06:21 PDT 2009

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

The runtime type information is precise, so it can't get the descriptor

Also, the compiler *does* do that.  _Jv_BuildGCDescr is only used when
we generate classes on the fly, which we can do as well as precompiling.


> 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.

More information about the Gc mailing list