[go-nuts] Hacking gccgo heap?

I think there may be ways to hack the gccgo heap to use SOA memory layout
(structure of arrays) rather than AOS, even though the GC is conservative
rather than precise. I'm making a lot of likely incorrect assumptions, but
would something like this work? It is not clear from the language
specification, but goroutines must yield control to allow others to run,
right? Can I assume GC is only done once all threads have yielded, so we
can assume the registers do not contain important root pointers into the
heap? If all this is right, then would the following work?

- First, only objects on the heap would be changed. Objects on the stack
would work as they do now.
- Heap object field access needs to be done through static inline functions
(or macros or equiv).
- To insure all heap access is being done through the accessor functions,
I'd return modified pointers that point to unallocated space. Any place
the system does a direct read/write would cause a memory violation.
- Initially, the accessor functions would just add/subtract some random
constant to convert the invalid pointer to the real pointer and vise versa.
- Once the accessor functions are enforced and known to work, changing the
memory layout should be trivial, so long as it is transparently done by the
accessor functions
- Pointers to struct fields would simply return pointers to the actual
field, wherever it is in memory.

Where would be a good place to start to try and figure out how the gccgo
heap related code works?

Thanks,
Bill