memory mapped i/o?

[Boehm, Hans]

> From: Jeff Sturm [ mailto:jsturm@detroit.appnet.com ]
> 
> David Brownell wrote:
> > Just curious ... has anyone done work to make GCJ work well
> > with memory mapped files?  It seems to me that would call for
> > some smart hookups to the garbage collector, but it shouldn't
> > be that hard unless there are assumptions being made about
> > ability to relocate data.  (Speaks someone who's rarely had
> > to look at that level of a JVM ... ;-)
> 
> The GC will ignore memory regions outside the heap, including mmap'ed
> regions.  Such regions must not contain pointers to live 
> objects, unless
> care is taken that those objects are also reachable from some root. 
> Otherwise there is no problem with GC.
The advice is correct.  Unfortunately it's actually platform dependent
whether the collector sees read-write mapped files.  (The intent was to
exclude them.  But in some cases it's hard to include dynamic library
data without also including these mappings.)  It's probably a good
idea to explicitly tell the collector whether or not to include these in the
root set.  There are hooks to tell it either way.
> 
> > I could see a variety of applications (webpage serving and
> > some video apps come to mind :-) benefitting from such stuff.
> > (But so far as I know, Sun's JCP hasn't looked at this.)
> 
> The problem as I see it is that the memory region must be 
> copied to/from
> a Java array to be useful.  This copy defeats the advantages of memory
> mapping somewhat.  It would be convenient to create primitive arrays
> directly mapped to a file, but gcj cannot easily do this because the
> array requires an object header.
But that doesn't sound like a showstopper if someone really wanted to
implement this, right?  One could presumably map the preceeding page to
/dev/zero, and cons up a header inside it.  Getting the regions mapped
contiguously is slightly messy, but possible. 

Hans