Re[6]: [Gc] Allocating Executable Memory

Ivan Maidanski ivmai at mail.ru
Sat Jul 24 13:19:11 PDT 2010


Hello!

I've changed the patch a bit.

Noah -

Could you test it?

Hans -

We unconditionally allocate executable pages on Win32. In the patch, I've changed this to behave the same way as for Unix. Do you think it's worth doing?


Sat, 24 Jul 2010 02:16:29 -0400 Noah Lavine <noah.b.lavine at gmail.com>:

> Ooops! Here it is.
> 
> 2010/7/24 Ivan Maidanski <ivmai at mail.ru>:
> > Hello.
> >
> > You forget to attach the patch.
> >
> > Fri, 23 Jul 2010 20:32:47 -0400 Noah Lavine <noah.b.lavine at gmail.com>:
> >
> >> 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/
> >> >
> >> >
> >>
> >> _______________________________________________
> >> 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 12630 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100725/5b750fae/attachment.obj


More information about the Gc mailing list