Re[7]: [Gc] Allocating Executable Memory

Ivan Maidanski ivmai at mail.ru
Sat Jul 24 13:38:47 PDT 2010


I've checked the patch more thoroughly on Win32 and found typo in it (PAGE_READ instead of PAGE_READONLY). The attached patch is the corrected one.

Sun, 25 Jul 2010 00:19:11 +0400 Ivan Maidanski <ivmai at mail.ru>:

> 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/
> 
> 
> 
> ATTACHMENT: application/octet-stream bdwgc-ivmai-244.diff_______________________________________________
> 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: 12634 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100725/fcbfda57/attachment-0001.obj


More information about the Gc mailing list