[Gcl-devel] Re: copy-on-write

[Camm Maguire]

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 <address@hidden> 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                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah