GCC JIT vs others JIT ....

[David Malcolm]

On Fri, 2013-10-25 at 13:15 -0200, Paulo César Pereira de Andrade wrote:
> 2013/10/24 David Malcolm <dmalcolm@redhat.com>:
> > On Wed, 2013-10-23 at 19:05 -0200, Paulo César Pereira de Andrade wrote:
> > [...]
> >
> >>   It is a C/C++ like language, with static and dynamic typing. The only
> >> examples so far are in check/test, that you can cut&paste under gdb,
> >> or just run "./owl check/test" to run all examples in a row. The file is quite
> >> large, and growing, to help stress test the current implementation.
> >
> > Is OWL compiling a function at a time (a "method JIT"), or are you
> > tracing execution paths and then optimizing hot loops (a "tracing JIT")?
> > (I've only attempted the former so far with my work)
> 
>   For now it is more of a test environment for complex code generation
> using lightning. It actually "compiles" a full owl script as a single C
> callable function, uses its own stack, and does a precise mark&sweep
> gc. Lightning itself can be used for either, as it only provides a kind of
> portable, minimal assembly.

Nice.

> > [...]
> >
> >>   My interest is in  writing a managed language with dynamic typing,
> >> and static typing for faster execution. But porting to gcc jit should not
> >> be much different from the initial code I am writing, mainly to exercise
> >> lightning, that would "optimize" when types are know, check for overflow
> >> when it can happen and otherwise fallback to calling functions to
> >> implement the vm primitives.
> >
> > BTW, does lightning support self-modifying code?   (e.g. for doing
> > inline caching of attribute lookup).
> 
>   No. Lightning does mmap memory for the jit, attempting to waste as
> few as possible memory, and after code generation it does mprotect
> it removing write permission. Also does some voodoo for architectures
> that need complex sequences to flush the code cache; currently
> it requires gcc as the compiler, but libgcc __clear_cache does not
> work on all ports.

Thanks.

FWIW one other approach I've seen is to mmap an anonymous fd twice, once
as writable, once as executable, giving the same underlying pages in two
different locations in the address space.   IIRC libffi uses this when
constructing wrappers to sidestep SELinux's restrictions on having pages
that are both writable and executable.   (I don't think that it has a
cache-flushing mechanism, since it has clearly separated phases of
"write,  then execute").