Porting Boehm-gc to embedded m68k environment

["John Neil" <jneil at atrove dot com>]

I am currently porting gcj and the boehm gc to an embedded m68k environment.
The port is basically working I, however I have a few queries.

1.  The GC_alloc function(s) calls a clear stack function just prior to
returning.  I assume that this function is used to clear old addresses from
the unused partition of the stack however as there seems to be no bounds on
range cleared, this function overwrote the end of the thread stacks which
are relatively small stack (~2k).  I was wonder if this stack clearing is
really necessary if the correct stack bounds (top to current) are registered
for scanning via the GC_push_stack function.  I have replaced this function
internally and was wondering if it this should be provided via the
"os_dep.c" file.   Alternatively a function could be added to limit the
clearing to some real stack bounds, for example returning the end of the
current threads stack and clearing between the current sp and stack end.

2.  Are the memory pages returned via the GET_MEM function automatically
added to the list of ranges to be scanned for addresses, or is it necessary
to manually add these, via add-roots or push all when the stacks are pushed
for scanning.

3.  Why do the Jv_realloc and Jv_malloc functions in prims.cc us
realloc/malloc directly rather than the corresponding GC function's
GC_malloc/GC_alloc.  Is this for efficiency reasons, to reduce the amount of
memory the GC has to scan during a collection.

4.  As garbage collection takes considerable time (1.5 sections for 6M) I
was looking at limiting the amount of memory scanned.  I noticed that static
final primitive fields (int, byte, ...) are stored in the .data section,
with all other static fields stored in the .bss section.  I figured that
static final fields which are java primitives should actually be stored in
read-only data sections (.text/.rodata), and static primitive fields which
are initialized (by constants) should be stored in the .data section (and
initialized at load time) rather than the .bss section (and initialized at
runtime).  Is there any reason why initialized static primitive fields are
not stored in the .data section. 

As no class pointers are stored in the .data section, is it true that only
the section .bss needs be scanned by the garbage collector.  The .bss
section would be considerably smaller if all initialized static primitive
fields where stored on the .data section, making the scan quicker.
Alternatively would it be possible to have a special section of java static
class fields.  This does not take into account native variables (c/c++)
which may include contain java class pointers.    

Cheers
John