Re[2]: [Gc] RE: Abuse of collector...

Ivan Maidanski ivmai at mail.ru
Mon May 18 10:13:30 PDT 2009


Hi!

"Talbot, George" <Gtalbot at locuspharma.com> wrote:
> Sorry, I spoke incorrectly.  What I meant was that for a C++ program, I'd be afraid of getting the layout wrong if I wrote code to do it myself, and would like to have the compiler generate the descriptor for C++ classes too.

The other question is, whether your app could speed-benefit of bitmap-based descriptors on a 64-bit arch?
In case of length-based ones, the collector just scans obj_base..last_obj_ptr region. In case of bitmap, it, at least, has to "parse" that map to determine what fields to scan.
The primary goal of GCJ-style/typed (any-based) allocation is to minimize possibility of false marking (of unreachable objects) for a 32-bit arch.

Of course, manual use of GCJ-style allocation is not a simple task (but this could be done selectively, only for some 'critical' objects).

> 
> --
> George T. Talbot
> <gtalbot at locuspharma.com>
> 
> ________________________________________
> From: Andrew Haley [aph at redhat.com]
> Sent: Monday, May 18, 2009 12:06 PM
> To: Talbot, George
> Cc: gc at napali.hpl.hp.com; 'Ivan Maidanski'
> Subject: Re: [Gc] RE: Abuse of collector...
> 
> 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
> wrong.
> 
> 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.
> 
> Andrew.
> 
> > 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.

Here I meant GCJ API of GC not GCJ itself. AFAIK, eg., mono uses length-based descriptors.

Bye.


More information about the Gc mailing list