[Gc] Allocating Executable Memory
noah.b.lavine at gmail.com
Fri Jul 23 12:21:34 PDT 2010
Thanks a lot!
Here is a patch against the latest CVS which implements this. On my
computer libgc passes all tests with it applied.
On Fri, Jul 23, 2010 at 3:10 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> I don't mind this either. We've generally been moving static configuration options to runtime wherever the performance impact was minor. We didn't get around to this one yet.
>> -----Original Message-----
>> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
>> On Behalf Of Ivan Maidanski
>> Sent: Friday, July 23, 2010 11:40 AM
>> To: Noah Lavine
>> Cc: gc at linux.hpl.hp.com
>> Subject: Re: [Gc] Allocating Executable Memory
>> 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
>> > 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
>> > 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
>> > 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
>> > this?
>> See GC_add_roots.
>> > Thank you very much
>> > Noah Lavine
>> > _______________________________________________
>> > Gc mailing list
>> > Gc at linux.hpl.hp.com
>> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>> Gc mailing list
>> Gc at linux.hpl.hp.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2456 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100723/57cf5899/add_executable_option.obj
More information about the Gc