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

Ivan Maidanski ivmai at
Fri May 22 02:10:25 PDT 2009


A week ago I wrote:
> Hi!
> "Talbot, George" <Gtalbot at> wrote:
> > > -----Original Message-----
> > > From: gc-bounces at [mailto:gc-bounces at]
> > > 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?
> 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 (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 GC_write_fault_handler()?
> 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 mailing list