[Gc] Patch for avoiding a page waste in Win32 GET_MEM
ivmai at mail.ru
Wed Sep 16 13:27:17 PDT 2009
This patch (ivmai142.diff) does 3 things (for Win32 only):
- if we are not using MPROTECT then we don't need to have a gap between allocated regions;
- minor thing: if we use GlobalAlloc then don't use GWW;
- very minor: if we use GlobalAlloc then (according to the comment in Makefile.direct) disable unmapping at runtime (this is for safety only, and, if I've red the code correctly, the code is for dead win32s only, so not a big deal anyhow).
* include/private/gcconfig.h (GWW_VDB): Undefine if
USE_GLOBAL_ALLOC (since incompatible).
* os_dep.c (GetWriteWatch_alloc_flag): Define as 0 unless GWW_VDB
* os_dep.c (GC_unmap_threshold): Declare (for use in
GC_init_win32) if USE_MUNMAP.
* os_dep.c (GC_init_win32): Turn off memory unmapping if
GlobalAlloc() is used.
* os_dep.c (GC_win32_get_mem): Define and use new
VIRTUAL_ALLOC_PAD macro; don't waste a extra memory page unless
MPROTECT_VDB is in use.
PS. Hans wrote:
> In general, it might help if you were even more explicit about what you are going to do with a patch. ...
Typically, my patches are neither theoretical/experimental, nor hot-patches.
I'm not going to introduce new features any more (at least in this release).
The things that should be fixed (IMHO), not counting this post, are:
- overflow in GC_win32_get_mem() (I suggest introduce GET_MEM_SCRATCH=VirtualAlloc, see my next post);
- a minor issue for WinCE (optional removal of automatic GC_init thru WinMain supplied by GC - unconditional export of WinMain frm GC could result in multiple symbol definition linker error in some cases (eg., if the application supplies main() (which does GC_INIT()) and some toolchain "standard" lib supplies WinMain() wrapper)).
PPS. If no comments/objections, I'll commit it in several days.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3121 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20090917/d8d0c295/ivmai142.obj
More information about the Gc