Re: [Gc] Allocating Executable Memory
ivmai at mail.ru
Fri Jul 23 11:39:46 PDT 2010
I like the idea.
I don't mind adding this feature in this release (probably Hans wouldn't neither since the added coded is small and easily verifiable).
The API should be:
- GC_set_pages_executable(int) // non-zero means executable
- GC_get_pages_executable() // returns non-zero if it is allowed to execute code in allocated memory
NO_EXECUTE_PERMISSION controls the initial value only.
If you'd like to add it, I expect you'll provide the patch against the current CVS.
Fri, 23 Jul 2010 13:28:17 -0400 Noah Lavine <noah.b.lavine at gmail.com>:
> Hello GC Developers,
> I am writing with a feature request for the next version of your library.
> I am working on adding JIT compilation support to GNU Guile (a Scheme
> implementation), which uses this library for garbage collection. In
> order to make GC work, we'll need to allocate executable memory.
> However, I have discovered that allocating executable memory is a
> build-time configuration option (in version 7.1, it appears to be set
> in configure.ac, at lines 401 and 495). This gives Guile something of
> a problem - currently we use whatever libgc is on a user's computer.
> However, the only way to ensure that libgc will allocate executable
> memory would be to build our own version of it, which would add space
> to our executable and be redundant. We could also hack together our
> own memory allocator only for executable memory, but we like using
> your library. :-)
> Therefore, I'd like to request that the next version of the library
> have allocating executable memory as a runtime configuration option
> that can be set by programs. I don't think it would affect performance
> very much - in fact, I can find only two uses of it in the entire
> program (calls to mmap and mprotect in os_dep.c).
> I also have a question - is there some way to make an older version of
> libgc manage executable memory anyway? For instance, if I mmap some
> pages of executable memory, will libgc scan those for pointers even
> though it didn't allocate them? Are there other ways to work around
> Thank you very much
> Noah Lavine
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc