RE: Array marking

["Boehm, Hans" <hans_boehm at hp dot com>]

I wouldn't bother with GC_malloc_stubborn.  It was intended as a way to
enable incremental collection without the right VM support.  And in
retrospect, I don't think it was the right way to do that.

It looks like I can get another few percent in GC performance by suitable
insertion of prefix instructions, at least for heaps with reasonable amounts
of live data.  The problem with doing that on X86 is that AMD and Intel
couldn't agree on the opcodes.  Eventually we may need to clone the mark
code, and switch dynamically depending on the processor.

On a separate issue: I still haven't had a chance to track down a problem
with gctest on win32 with GC 5.0 alpha6.  I don't know whether this is a
regression, or an old bug that was hidden before.  If you are working on a
win32 platform, you might want to be cautious about updating.
(-DREDIRECT_MALLOC is also completely broken on Linux in 5.0 alpha 6.  But
that shouldn't affect gcj, and will be fixed shortly.)

Hans

-----Original Message-----
From: Tom Tromey [mailto:tromey@cygnus.com]
Sent: Saturday, April 22, 2000 6:36 PM
To: Jeff Sturm
Cc: Bryce McKinlay; Tom Tromey; java-discuss@sourceware.cygnus.com
Subject: Re: Array marking


Jeff> I was wondering too if using GC_malloc_stubborn for known
Jeff> immutable objects (e.g. java.lang.String) could help... or if
Jeff> that is mainly for incremental mode?

I don't know.  One thing to note is that with the current
synchronization implementation, every object is mutable.  This can be
changed (the compiler part of this is done), but nobody has done so.
Synchronization is something that comes up periodically here.  I'd
like to get a chance to do some work on that, but so far it hasn't
happened.

Tom