[Gc] Alignment, Executable memory and MMX registers
ben.hutchings at businesswebsoftware.com
Mon Oct 18 03:38:16 PDT 2004
Matt Bromberg <doom_portfolio at yahoo.com> wrote:
> I am experimenting with using the garbage collector in
> my compiler project. The final code my compiler
> generates is fasm compatible assembly on a Win32 X86
> platform. I link to your garbage collector via a
> dynamic link (DLL) library. My compiler makes
> extensive use of Intel's SIMD instructions that use
> the MMX registers and (eventually) the XMM registers.
> My questions follow:
> 1) Do you include the MMX registers and/or the XMM
> registers in your root set?
No. The root sets includes EAX, EDX, ECX, EBX, ESI, EDI and EBP for
all threads. For the thread running the collection this is
controlled by GC_push_regs() in mach_dep.c and for all other threads
it is controlled by GC_push_all_stacks() in win32_threads.c.
> 2) For your Win32 port, can I execute machine
> instructions written to allocated memory? I'm
> thinking of adding a JIT compilation mode to my
> language and I'm concerned about WinXP SP 2 memory
> security stuff. The only way I know how to make
> allocated memory executable is using VirtualAlloc()
> with the right permissions set.
Currently I believe it's allocated as executable unless you define
the USE_GLOBAL_ALLOC macro.
> 3) I plan to allocate memory for the use of double
> arrays that probably should be 16 byte aligned. Is
> there an easy way to obtain my desired alignment with
> GC_malloc() et. al..?
The ALIGN_DOUBLE macro forces alignment on 8-byte boundaries (on
32-bit machines) but there is nothing similar to force greater
It would perhaps be simplest to use wrappers like these:
void * GC_malloc_align16(size_t sz)
return (void *)((size_t)GC_malloc(sz + 12) + 12 & ~15);
void GC_free_align16(void * p)
> 4) Since I'm not using C, but rather assembly and
> linking in the garbage collector as a DLL is it
> possible I will run into problems due to assumptions
> concerning C compiled executables?
I don't see that as likely.
> I must say I do
> not fully understand the magic involved in how you get
> the data segments into your root sets, especially if
> libraries are loaded dynamically at run time.
The collector should find them by scanning the address space with
VirtualQuery. If they are later unloaded, leading to an access
violation while scanning, this should be caught and fixed up using
Structured Exception Handling (SEH). This doesn't work on compilers
that don't support SEH, though.
> I also
> don't understand how you deal with the mutator messing
> up the integrity of your marked data, unless you go
> through the whole tree every time you garbage collect,
> or possibly lock out memory locations and force an
> interrupt or something.
Currently, on Windows, the collector does go through the whole tree
(or rather graph) of objects referred to from the root set. There
are techniques called generational and incremental garbage collection
that can avoid this, but the necessary supporting code has not yet
been written for Windows. I may do so at some point.
> Finally if no one else has said it, I think this
> whole effort is a God-send to free software
> developers, and you have my heartfelt thanks.
It's also useful for evil proprietary developers like me. >;-)
More information about the Gc