[Bug libgcj/19823] java fails with non-executable memory

["Hans dot Boehm at hp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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 
configure.ac.

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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823