[Bug libgcj/19823] java fails with non-executable memory
Hans dot Boehm at hp dot com
Tue Feb 15 00:45:00 GMT 2005
------- Additional Comments From Hans dot Boehm at hp dot com 2005-02-14 19:38 -------
I'd like to see USE_MMAP set in boehm-gc/configure.ac instead of gcconfig.h.
There's already a comment there that we're not setting NO_EXECUTE_PERMISSION
for this reason, where the upstream version does set it. I also think we've
been trying to keep gcconfig.h shared, with gcj-specific adjustments in
It seems to me that, with this minor adjustment, this is clearly the right
short term fix.
I'm not sure that we should be turning on execute permission on all platforms,
though. I'm pretty sure it's unnecessary on IA64. I think it should be
unnecessary on all platforms on which function pointers point to an (ip, GOT)
pair. IIRC, that includes PowerPC? At least IA64 does not put trampoline code
in the closure.
Having said that, I'm not sure that having the Java heap be executable is a
major security risk.
There can occasionally be a large performance down side to making the heap
executable on some platforms, at least in the presence of incremental GC. I
know that some old Un*x versions ensured d-cache and i-cache coherency whenever
you made an mprotect call with the execute bit set. And this could take a
substantial amount of time.
Having the collector allocate both executable and non-executable memory sounds
non-trivial. Probably it would be easiest to add a new "kind" of pointer-free,
executable memory, and have the GC adjust permissions when a new block was
moced between kinds. But that may not be cheap (see above). And there are
issues if the physical page size is larger than the heap block size.
The alternative is to essentially keep a separate heap, which would require a
major code reorganization, and introduces a new and different kind of
fragmentation. I suspect it would be far easier to have the interpreter
allocate closures outside the Java heap.
More information about the Java-prs