Avi,

> >   Mark&sweep phase mutates the object headers, so almost of virtual
> > memory pages (4k bytes or so) are "modified" even if you avoid the
> > compaction.  Not doing compaction wouldn't change it.
> >
> >   Having a "full GC, fork and let the child write image to file"
> > should work, and the set of pages tainted in the period of concurrent
> > run may not be so big, actually.
> 
> Yeah, it doesn't seem to be.  I haven't done any detailed analysis,  
> but just watching the output of top, if you take out the GC basically  
> all you see is a chunk of memory being moved from the "resident" pile  
> to the "shared" pile and then back again when the child process  
> dies.  Whereas with the GC in the child, you get a large increase in  
> total memory use for that period.

  I may have misunderstood the problem, but I might still imagine that
adding a primitive that does

"full GC, fork and let the child write image to file"

"at once" (not returning the control to the image level on both child
and parent) may give some benefit.

-- Yoshiki