Greetings! Yep, if the child could tell which pages were copied out, that would work too. Alas, to my knowledge, this information is not available, at least in 'vanilla' C. I'd be most happy to be shown wrong here if anyone has info to the contrary.
There is yet another mechanism which is already available to us in principle -- SGC. If the object is on a read-only page, this would do too. But the overhead of si::sgc-on is too big, I think. In the commit I am now preparing. GCL will configure itself by default to allow as much stack allocation as possible, and use 80% of this in the child for fresh allocations. This can be turned off by setting si::*child-stack-alloc* (which needs to be renamed) to 0.0. (This now represents a percentage of available stack space in the child to use fo allocations -- some will be needed for function calling too.) On default Debian Linux, the child has more stack allocation space available (in principle) (2 Gb) than the max available heap (1Gb) when using dynamic linking! Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > Here's a dim thought along the lines your child-stack-allocation idea, but > not stack-related. From the man page on fork: > > > Under Linux, fork is implemented using copy-on-write > > When the child is about to return, if the value to be returned is on a > copy-on-write page, then it must have been created back in the parent and > still be there, assuming the parent has been holding on to it. As you > observe, a key thing is to ask the child to avoid doing a garbage collection; > better, for a while anyway, for the child to just allocate fresh new pages so > as not to unnecessarily write to copy-on-write pages. > > Bob > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
