GCC JIT vs others JIT ....

[Paulo César Pereira de Andrade]

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.

> [...]
>
>>   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
> Dave

Paulo