[Gc] Allocating Executable Memory
cr88192 at hotmail.com
Mon Jul 26 07:37:03 PDT 2010
----- Original Message -----
From: "Andrew Haley" <aph at redhat.com>
To: <gc at linux.hpl.hp.com>
Sent: Monday, July 26, 2010 6:29 AM
Subject: Re: [Gc] Allocating Executable Memory
> On 07/24/2010 11:04 AM, Ivan Maidanski wrote:
>> Sat, 24 Jul 2010 09:50:38 +0100 Andrew Haley <aph at redhat.com>:
>>> On 07/23/2010 07:39 PM, Ivan Maidanski wrote:
>>>> Fri, 23 Jul 2010 13:28:17 -0400 Noah Lavine <noah.b.lavine at gmail.com>:
>>>>> 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.
>>>> 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.
>>> I think you'll find this problematic in practice, at least on
>>> GNU/Linux. Some distributions forbid the allocation of memory that is
>>> mapped writable and executable, and I think the number of such
>>> distributions will increase over time. On such systems Java is marked
>>> with a special file attribute, and that attribute is writeable only by
>>> The way around this is supposed to be to map pages twice, with
>>> writable and executable permissions.
>> Okey. Another patch is needed which adjust the method how mmaping is
>> If I understand correctly, we just need to duplicate all relevant
>> mmap and munmap calls (RW + E), right?
>> If yes, we also need some config option to enable this feature
>> (otherwise retain old behavior).
> Unfortunately, it's harder than that. On such systems, the only way
> to solve the problem is to map each page twice, at different
> addresses. As far as I know, the only way to do that is to use mmap()
> on a named file on some device.
> In practice the easiest way to do this is to map the pages
> independently of the gc and use finalizers to recycle pages once
> they're no longer reachable.
how about mode changing?...
like, a call is used to mark the memory object writable, and another to mark
it executable? (via mprotect or similar...).
on systems without this issue, these calls could be no-op.
I guess another option, although more specific to JIT, would be to have a
specialized linker which manages the executable memory, and itself would
worry about any such issues (be it mode-changing or multiple mapping).
so, when one wants to submit code, they can do so as a COFF or ELF module
(or possibly something simpler, like a glob of memory and a
in my case, I typically link code via such a linker API, and it is very rare
that any other code will try to write into the memory.
admittedly, I don't really know why distros would make this restriction, as
personally it seems restrictive and ill-concieved (and liable to break many
otherwise functional apps). one could almost just ignore the issue and make
the app break on these targets, as a sort of protest against this "feature"
(users have to patch themselves, and one can refuse to accept patches to
"fix" this feature as a matter of project policy), and if the apps become
popular, then it puts pressure on them to forsake such a feature.
then again, I typically also develop on Windows via MSVC, and it is notable
in how many ways MS and most OSS people do things differently, ...
More information about the Gc