Hello,
Here is a second version of the patch. I believe it fixes almost
everything you said. However, I have a question about changing the
behavior on non-unix platforms: the code suggests that these platforms
currently don't obey the NO_EXECUTE_PERMISSION configure option, and
just always return executable memory. I can change that, but it seems
like a separate issue from this change - would you like it as a
separate patch?
A ChangeLog entry could look like this:
2010-07-23 Noah Lavine <noah.b.lavine at gmail.com>
* configure.ac: change documentation for NO_EXECUTE_PERMISSION
to match following change.
* os_dep.c: add functions GC_set_executable_pages(int),
GC_get_executable_pages() to set and check whether the GC allocator
functions will return executable memory. Make the
NO_EXECUTE_PERMISSION configuration option determine the default
choice.
* gc.h: add prototypes and documentation comments for
GC_set_executable_pages(int) and GC_get_executable_pages().
There's also a larger issue which I wanted to ask about because I
don't understand the internals of libgc very well: my original idea
was that the executable option would take effect immediately after
being changed. However, I realized that for instance
GC_set_pages_executable(1) could be called at a time when the GC has
partially-allocated non-executable pages that it is giving out. Would
it be better to try to change the protection on those pages, save them
and allocate new executable pages, or just change the documentation on
this option so it can only be called just after the library is
initialized?
Thanks
Noah
2010/7/23 Ivan Maidanski <ivmai at mail.ru>:
>> The patch is incomplete. gc.h should be affected too. Also supply better doc comments (in gc.h). Update NO_EXECUTE_PERMISSION documentation. Send me Changelog entries please. Also, PROT_EXEC is not defined for every platform (e.g. Win32 which supports executable code in the allocated memory) - we shouldn't define a static variable which is always a const. GC_get_pages_executable() should better actually return 1/0 instead of exec_flag.
>> Fri, 23 Jul 2010 15:21:34 -0400 Noah Lavine <noah.b.lavine at gmail.com>:
>>> Thanks a lot!
>>>> Here is a patch against the latest CVS which implements this. On my
>> computer libgc passes all tests with it applied.
>>>> Noah
>>>> 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.
>> >
>> > Hans
>> >
>> >> -----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
>> >>
>> >> Hello!
>> >>
>> >> 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
>> >> > 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>> >> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>> >
>>>>>> ATTACHMENT: application/x-patch add_executable_option.patch_______________________________________________
>> Gc mailing list
>>Gc at linux.hpl.hp.com>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>>