[Gc] Workaround for problems with GetWriteWatch and GC_get_unmapped_bytes

Boehm, Hans hans.boehm at hp.com
Fri Aug 7 17:50:04 PDT 2009


Thanks.  Committed.

Hans 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, August 06, 2009 6:26 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Workaround for problems with GetWriteWatch and 
> GC_get_unmapped_bytes
> 
> Hi!
> 
> The attached patch does all as suggested below (plus API 
> GC_get_unmapped_bytes() is introduced).
> 
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > Thanks.
> > > From:  Ivan Maidanski
> > > 1. MPROTECT_VDB only. As in some cases on Win32 the 
> exception-based 
> > > approach of incremental collection may work better than 
> > > GetWriteWatch-based one then there should be a way to select the 
> > > one. So, GC_PREFER_MPROTECT_VDB macro and GC_USE_GETWRITEWATCH 
> > > environment variable are introduced.
> > This part looks good to me.
> > 
> > > 2. The values returned by GC_get_heap_size() and
> > > GC_get_free_bytes() if USE_MUNMAP. If the memory is unmapped 
> > > (returned to the OS) then the values indicating the current heap 
> > > size and the free memory size should be updated accordingly 
> > > (otherwise, the total heap size of several applications 
> running on a 
> > > system may become larger than the system virtual memory size, and 
> > > the memory considered as "free" by one application may 
> be, in fact, 
> > > in use by another one).
> > ...
> > If the underlying problem here is the values we're 
> reporting back to the user, does it make more sense to just 
> keep track of the total amount of unmapped memory in a 
> separate variable, and subtract it in GC_get_heap_size and 
> GC_get_free_bytes, leaving the internals alone?  That strikes 
> me as safer and easier to maintain.  Plus we have more 
> information for debugging.
> 
> This patch is against the current CVS, it supersedes 
> diff101_cvs fully (which, in turn, resembles diff52, diff75, 
> diff83 partly), it doesn't depend on any of my other pending patches.
> 
> ChangeLog entries:
> 
> 	* Makefile.direct (MARK_BIT_PER_OBJ, PRINT_BLACK_LIST,
> 	USE_PROC_FOR_LIBRARIES): Fix typo in the comments.
> 	* Makefile.direct (USE_MMAP, USE_MUNMAP, THREAD_LOCAL_ALLOC,
> 	PARALLEL_MARK, STATIC): Update the comments.
> 	* include/private/gcconfig.h (GC_PREFER_MPROTECT_VDB): New macro
> 	recognized (only if MPROTECT_VDB).
> 	* Makefile.direct (DONT_USE_USER32_DLL, GC_PREFER_MPROTECT_VDB):
> 	Add the comments for.
> 	* os_dep.c (detect_GetWriteWatch): Recognize 
> "GC_USE_GETWRITEWATCH"
> 	environment variable (only if MPROTECT_VDB, if the variable is
> 	unset when GC_PREFER_MPROTECT_VDB macro controls the strategy).
> 	* doc/README.environment (GC_USE_GETWRITEWATCH): New variable.
> 	* include/private/gcconfig.h (MPROTECT_VDB): Add FIXME for
> 	USE_MUNMAP and PARALLEL_MARK cases (to relax the conditions in
> 	the future).
> 	* misc.c (GC_get_heap_size, GC_get_free_bytes): Ignore 
> the memory
> 	space returned to OS (GC_unmapped_bytes).
> 	* include/gc.h (GC_get_heap_size, GC_get_free_bytes): Update the
> 	comments.
> 	* misc.c (GC_get_unmapped_bytes): New API function.
> 	* include/gc.h (GC_get_unmapped_bytes): New API prototype.
> 	* include/private/gc_priv.h (GC_unmapped_bytes): Define as 0 for
> 	not USE_MUNMAP case.
> 	* os_dep.c (GC_dirty_init): Move "ifdef GWW_VDB" block out of
> 	"ifdef MSWIN32" one (for Cygwin).
> 
> Bye.
> 


More information about the Gc mailing list