memory mapped i/o?

David Brownell
Fri Dec 15 14:17:00 GMT 2000

">"            == Tom Tromey
"> David> "    == me

Tom, I'm not sure I understand why you say:

> If you want to have the mmap'd memory show up as something other than
> byte[], then you'll need to do some alignment computations here:
> David> X    array = (jbyteArray) (data - sizeof *array);

I can see needing a different data type (array is a jbyteArray)
and vtable, but nothing related to alignment seems obvious.

The "data" is already maximally aligned (page boundary), and must
be ... are you saying that there's something about the GCJ ABI
gives additional alignment requirements for that array header?

Though in this case, I very much want the memory to be opaque,
a byte array ... otherwise I get into issues like byte ordering
(OK if it's a memory segment attribute, otherwise could affect
code generation!) and garbage collection of pointers in mapped
segements.  I'd want to save such stuff for later!

(Though if anyone wants to discuss a preferred Java API for such
functionality, I'm up for it.  It could let applications using
GCJ do things that ones using Sun's APIs can't ... ;-)

> In the current CVS, `length' is const and you can only assign to it
> via a const_cast.  Here's the line that would have to change:
> David> X    array->length = (jsize) statb.st_size;
> I made this member const because it is conceptually more correct,
> reduces the possibility of introducing a bug, and might make it
> possible to optimize a little better in some situations.

When I try that version, I'll surely end up updating that code!
For the moment I'm sticking to the GCJ in RH7.  (Yes, in this case
it's also constant except as it's being initted.)

Hans also suggested calling GC_exclude_static_roots to make the
garbage collector completely ignore those mapped regions, just
in case it notices them.

- Dave

More information about the Java mailing list