------- 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
