[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mmap in guile -- guile memory management question

From: Daniel Ridge
Subject: Re: mmap in guile -- guile memory management question
Date: Tue, 5 Dec 2006 22:23:14 -0500

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]