Re: mmap in guile -- guile memory management question

[Daniel Ridge]

With the existing universe of UNIX semantics, copy on write for  
substrings could be built tediously by creating a new MAP_PRVIATE map  
of the same object as the parent. This would be reasonable only in  
the cases that the syscall overhead was a worthwhile trade against  
the memory copy and:
        * the parent map was MAP_SHARED and msync can be called
	* the parent map was MAP_PRIVATE and making a new MAP_PRIVATE copy  
of the parent object complete with the parent's edits is feasible

I'm not really excited about either of these. Some UNIX kernels are  
drifting towards finer programmer control over virtual memory that  
might make it reasonable to get this in other ways.

For instance, we can imagine a mmapable pseudo-file (like /proc/xxx/ 
mem on linux) that would allow us to build a MAP_PRIVATE copy of  
something we already had in core. For very large strings, the syscall  
penalty might be worthwhile. In other cases, building a MAP_SHARED  
copy of a substring might let us preserve the existing sharing  
semantics of substrings together with an ability to do partial gc on  
the parent string.


On Dec 4, 2006, at 10:17 PM, Kevin Ryde wrote:

> Neil Jerram <address@hidden> writes:
> > Yes from me; it sounds interesting and useful.
>
> Me too.
>
> Stringbufs have room for another flag that could say they're mmaps
> (and hence should free with munmap).
>
> I suppose a string is only good while strings are uninterpreted
> 8-bits.  When they're some encoding I guess it has to be u8vectors or
> whatever r6rs introduces.
>
> One thing to contemplate if using strings would be how the string
> copy-on-write stuff should work.  If file contents are changing then
> you might not want `substring' to defer the copy (yet most of the time
> you probably do want to defer).




> _______________________________________________
> Guile-user mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/guile-user