Allocating Executable Memory

[Alex Rønne Petersen]

On 31-07-2012 20:06, Maxime Chevalier wrote:
>> Yep. Anything core.* and std.* is part of druntime and phobos which
>> both ship with any D 2.0 compiler.
>
> Thanks very much for the quick responses.
>
> My tracing JIT will likely need to have the compiled code write into
> data structures of the host VM. This will mean the compiled code holds
> pointers to host data.
>
> How well does the D GC deal with immovable objects. Would it be a
> problem if I allocated many chunks of immovable data?

Can you clarify what you mean by immovable data? I don't think I follow.

In any case, if the compiled code's executable memory regions aren't 
added as root ranges to D's GC (which is entirely reasonable to not do), 
then you can keep the data alive by simply keeping pointers to the D 
GC-managed data in the host environment. D doesn't use a moving collector.

>
> Would it be preferable to minimize immovable data by having compiled
> code refer to an (immovable) table with pointers to (movable) host data?
>
> Also, if you don't mind me asking, which D compiler do you guys prefer?
> Which one is most widely supported, most up to date?

DMD: Latest updates, fixes, and enhancements. Very fast compilation. Not 
that great optimization.
GDC: Best optimization and fantastic debug info generation. Somewhat 
slow at compilation.
LDC: Fast compilation and good optimization. Sits somewhere between DMD 
and GDC.

Note that DMD can only target x86 while LDC and GDC (due to using LLVM 
and GCC respectively) can target many other 32-bit and 64-bit architectures.

Also, LDC and GDC tend to lag one release behind DMD sometimes, since 
they rely on the DMD front end code.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org