Jittting Ocl Why Should We Compile Ocl
Jittting OCL : why should we compile OCL at run time?
Well, the quick answer is : writing compilers is like smoking you can never quit, really. The difference is : it's harmless. That may be why I got back at it on my leisure time.
So what's an OCL JIT Compiler anyway?
It's an OCL compiler. One that is able to generate code at run time just like the JIT does in the Java Virtual Machine.
Finally it's a compiler that directly generates java bytecode from an OCL String (no java source code is involved).
Finally it's a compiler that directly generates java bytecode from an OCL String (no java source code is involved).
Compilers always have an accompanying run time environment, especially JIT compilers. The environment for this one needs to be able to work with the compiled OCL requests for the compiler to be useful:
load the classes containing the compiled requests,call the requests,provide an execution environment to requests (resolve other requests, variables, or whatever is needed)etc,
Why a JIT Compiler, you would ask?
The alternative consists in generating Java source code from the OCL specifications attached to an Ecore meta-model and produce a deployable jar along with the Ecore meta-model classes or in a separate jar/plug in/whatever.
As compared to a compiler that generates java source code, the JIT compiler lets you handle OCL requests as mere strings as far as you're deployment target and still get fast evaluation. Whether it's used on you're deployment target or you're development environment doesn't make a difference.
In few words,it provides a lot of flexibility and ease deployment a lot by avoiding nasty binary compatibility issues.
As compared to a compiler that generates java source code, the JIT compiler lets you handle OCL requests as mere strings as far as you're deployment target and still get fast evaluation. Whether it's used on you're deployment target or you're development environment doesn't make a difference.
In few words,it provides a lot of flexibility and ease deployment a lot by avoiding nasty binary compatibility issues.
The last thing I'd like to mention about this approach is that it facilitates incremental development and early deployment. Indeed you don't have to complete the language covering to be able to start actually using the compiler in production and draw benefits from it. You can always rely on interpretation for those parts of the language that aren't supported by the compiler. If the supported operators are well chosen you can still get some interesting speedup for a fair amount of you're requests.
How does this work?
Well, like this :
As of today it also handles invalid evaluations:
To put it quickly the compiler generates a class file in a byte array and loads it in the VM through a dedicated class loader. Here's the class file disassembly for those that are bytecode inclined :
implement operation and request call (that involves many class loading issues and should be tackled early!)implement the select and collection stuff so as to have a lenient semantics (guava is on the call there!)design a run time environment that integrates smoothly with eclipse OCL (the compiler's already built on top of that)I should also do a performance study as soon as there are enough operators implemented :
What's next?
There's a lot left to do as the compiler only handles PropertyCall as of today. The next steps should be these additions:implement operation and request call (that involves many class loading issues and should be tackled early!)implement the select and collection stuff so as to have a lenient semantics (guava is on the call there!)design a run time environment that integrates smoothly with eclipse OCL (the compiler's already built on top of that)I should also do a performance study as soon as there are enough operators implemented :
Performance of the generated code should be examinedPerformance of the compiler itself should be examined as well.
Auteur d'origine: Romain