First fully functional JIT compiler for AngelScript available

This. is. cool.

One of these days I plan on using AngelScript... I just need to find a need for scripting first... and for that to happen I need to stop doing homework and work on hobby projects, but the homework never ends...

Anyway, I'm excited to use this in the future! Thanks Andreas (for AngleScript) and Blind Mind Studios (for the JIT compiler)!

This. is. cool.

QFE.

wow, that's impressive! the only gripe I have about it is that it depends on C++0x but that's not a critical thing, probably

Those tests are not rigorous, but still telling:
Large loop with raw arithmetic: 4 times faster.
Constructing and traversing a large "random" binary tree: 2 times faster (expected more here, no native calls are involved).
Bubblesort of ints array (with stock array addon): around 2.5 times faster.

I haven't had the chance to test it in production yet - first I have to eliminate the reliance on std::function as StlPort does not support it - but it appears very promising.

Hello everyone, I'm the owner of Blind Mind Studios, and responsible for the JIT. If you have any questions or suggestions, let me know.

Those tests are not rigorous, but still telling:
Large loop with raw arithmetic: 4 times faster.
Constructing and traversing a large "random" binary tree: 2 times faster (expected more here, no native calls are involved).
Bubblesort of ints array (with stock array addon): around 2.5 times faster

The binary tree is going slower than you might expect because the JIT doesn't natively handle context switches, for a variety of reasons. Any time a script function is called, the JIT has to return to the AngelScript context for it to allocate stack memory, locate pointers, etc. In the case of native calls, on the other hand, many are completely handled by the JIT.

wow, that's impressive! the only gripe I have about it is that it depends on C++0x but that's not a critical thing, probably

The primary use of C++0x is for lambdas due to so much use of local variables for the psuedo-assembly (each pseudo-register being a stack local variable).

Anyway, I'm excited to use this in the future! Thanks Andreas (for AngleScript) and Blind Mind Studios (for the JIT compiler)!

You're welcome!

You guys are awesome! Thank you so much for this contribution.

I think I´ve found a potential problem in the way the JIT is implemented in Angelscript. Blind Mind Studios´ web site shows a sample code for use with their JIT:

[source lang="java"]int main() {
asIScriptEngine* engine = asCreateScriptEngine(ANGELSCRIPT_VERSION);

//Create the JIT Compiler. The build flags are explained below,
//as well as in as_jit.h
asCJitCompiler* jit = new asCJITCompiler(0);

//Enable JIT helper instructions; without these,
//the JIT will not be invoked
engine->SetEngineProperty(asEP_INCLUDE_JIT_INSTRUCTIONS, 1);

//Bind the JIT compiler to the engine
engine->SetJITCompiler(jit);

//.............Setup some other stuff, compile and execute your scripts.....

//Clean up your engine. Code pages will automatically be cleared
//by the JIT when the engine is released.
DiscardModules();
engine->Release();
delete jit;

return 0;
}[/source]

The problem is in the last lines: when we call engine->Release(), we´re not destroying the engine, we´re just telling it that we won´t hold a reference to it anymore. The engine might continue to exist for some undefined time. Then we destroy (delete) jit, which actually destroys the JIT compiler (which is kind of the correct thing to do, otherwise we might be leaking memory). What if after that the engine (which still might be alive) tries to access the now defunct JIT? Crash! I think the JIT should also be a reference counted object.

I think I´ve found a potential problem in the way the JIT is implemented in Angelscript. Blind Mind Studios´ web site shows a sample code for use with their JIT:

[source lang="java"]int main() {
asIScriptEngine* engine = asCreateScriptEngine(ANGELSCRIPT_VERSION);

//Create the JIT Compiler. The build flags are explained below,
//as well as in as_jit.h
asCJitCompiler* jit = new asCJITCompiler(0);

//Enable JIT helper instructions; without these,
//the JIT will not be invoked
engine->SetEngineProperty(asEP_INCLUDE_JIT_INSTRUCTIONS, 1);

//Bind the JIT compiler to the engine
engine->SetJITCompiler(jit);

//.............Setup some other stuff, compile and execute your scripts.....

//Clean up your engine. Code pages will automatically be cleared
//by the JIT when the engine is released.
DiscardModules();
engine->Release();
delete jit;

return 0;
}[/source]

The problem is in the last lines: when we call engine->Release(), we´re not destroying the engine, we´re just telling it that we won´t hold a reference to it anymore. The engine might continue to exist for some undefined time. Then we destroy (delete) jit, which actually destroys the JIT compiler (which is kind of the correct thing to do, otherwise we might be leaking memory). What if after that the engine (which still might be alive) tries to access the now defunct JIT? Crash! I think the JIT should also be a reference counted object.

IMO you should just call SetJITCompiler(NULL);

/f

Alternatively you could store the jitcompiler as the script engine's user data, and register a cleanup function with the engine to delete the jitcompiler when the engine is deleted.

IMO you should just call SetJITCompiler(NULL);

/f

I don´t know if that´s a good idea - it should work only if Angelscript checks the jitCompiler pointer for NULLness and act accordingly.

Alternatively you could store the jitcompiler as the script engine's user data, and register a cleanup function with the engine to delete the jitcompiler when the engine is deleted.

The problem I see with this approach is that since one JIT compiler can serve many engines (Blind Mind Studios´ does) in a multi engine scenario it would be a problem to decide which of the engines has to delete the jitCompiler. So I still think that making the JIT a reference counted object might solve all that issues - the engines themselves would release such references when it is safe to do so. Of course the programmer should remember to release the original reference (the one created when he JIT was first constructed).

I tried to add this JIT compiler to my project and got may errors with std::function in MSVC 9 in as_jit.cpp .. Could you say me what I am doing wrong?

JIT needs c++11. lambda, auto, function
vc9 not supported.

saejox, thank you! you are opened my eyes, really)