memory mapped i/o?

Mon Dec 4 14:54:00 GMT 2000

> 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