[Gc] RE: Abuse of collector...
Gtalbot at locuspharma.com
Fri May 22 05:43:07 PDT 2009
On my setup, with both USE_MUNMAP and PARALLEL_MARK defined, there's no difference between incremental and stop-the-world collection.
George T. Talbot
<gtalbot at locuspharma.com>
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Friday, May 22, 2009 5:10 AM
> To: gc at linux.hpl.hp.com
> Cc: Talbot, George
> Subject: Re: [Gc] RE: Abuse of collector...
> A week ago I wrote:
> > Hi!
> > "Talbot, George" <Gtalbot at locuspharma.com> 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
> > > > (unlike linux32 or SunOS on amd64, or Win32 where the printed number
> > > > 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?
> > Suppose You are running gctest and/or your app with
> GC_ENABLE_INCREMENTAL=1, GC_MARKERS=1, GC_PRINT_STATS=1 (also I assume
> that you dont change default warn_proc in your app), GC_LOG_FILE=mygclog
> (for convenience).
> > Do You ever observe in the log file (first, check whether these msg are
> present in your libgc.so (this seems to be present only if REDIRECT_MALLOC
> is used)):
> > 1. "Incremental GC incompatible with /proc roots"?
> > 2. "Caught ACCESS_VIOLATION in marker."?
> > Q3. Check whether UNPROTECT() is ever called inside
> > Enough for this moment...
> > At present, I'm trying to track what's going on with it in Win32 (if the
> same strategy (mprotect and catch SIGSEGV) as in Unix is used).
> Discard my above thoughts and question!
> I see that point: on Linux MPROTECT_VBD is the only incremental collection
> strategy and it is disabled when USE_MUNMAP or PARALLEL_MARK.
> Solaris has PROC_VDB but I'm not sure it works under the same conditions
> (the last time I've tested it (a year ago) on i386, it wasn't).
> The new Q (not to You really): what's the impact of GC_ENABLE_INCREMENTAL
> if DEFAULT_VDB is the only one defined?
More information about the Gc