Discussion: An own ByteCodeCompiler for Dragome

[Prototype1]

Hi,

the current bytecode / js compiler is really messy and not really easy to extend. To create dragome specific features how about we write our own compiler, only for dragome. As reference projects we could use the github projects: J2JS and teavm.

What do you think?

On my dragome Dev branch i already did some steps to create an own compiler. Of course this is a huge task and not really easy to do. I did some class diagram to illustrate my idea (Only the parser right now, more to follow):

Feel free to post questions / enhancements / improvements or just an overall opinion.

[fpetrola]

Hi, I agree it would be nice to have a better architecture in bytecode compiler, current version is a mix a two compilers j2js and xmlvm that works together to process any kind of bytecode (instrumented or not) in order to produce good performance javascript code. To create a new implementation of the compiler we need to take into account some specific points of current implementation that are not present in other existent compilers:

• Dragome compiler produces js code that allows the use of java reflection API, others bytecode to js compilers don't have to do this because they don't support reflection nor dynamic proxies.
• Current compiler is incremental and the compiler is running also in runtime, this allows the use of hot deployment, copying just a .class file inside classes folder it is detected and compiled to generated a new code version without user intervention.
• Since all the compiled classes are autonomous just like in a JVM, and they are not compiled just for one particular execution (for example inlining some parts as), they could be separated in different .js files that can be cached in a very high level.
• Dragome compiler has two modes, one uses node reduction to achieve a high performance js code, and the second one is very similar to JVM execution mode to achieve highest compatibility execution.

Taking into account this items and some others, and knowing that it's difficult to find this features in others existing compilers it's a must to analyze very well which one could be used to create a new compatible implementation. I was researching some time ago a bytecode decompiler called Procyon that works like a charm for any kind of compilation of javac, eclipse compiler, etc. Having the ability to transform bytecode exactly to the original java source code in most cases. See examples here: https://bitbucket.org/mstrobel/procyon/wiki/Decompiler%20Output%20Comparison It would be nice to make some tests around it, to see if it's a good choice to start a new compiler.

I think that a good starting point for creating a new implementation is to separate qooxdoo js generation from compiler with a decoupled visitor layer that could be used in future compiler version without modification. Just creating an adapter for this abstract visitor should be enough to create the same js code. Current visitor structure was inherited from j2js but it must be improved or recreated from scratch to reach a highest decoupling level from the compiler itself.

[Prototype1]

Hi,

i am not really sure what you mean by instrumented bytecode. Is it the kind of stuff you do to detect model changes for the templatebinder?

To your points:

Current compiler is incremental and the compiler is running also in runtime, this allows the use of hot deployment, copying just a .class file inside classes folder it is detected and compiled to generated a new code version without user intervention.

Well, we could simply generate a hashcode about every class. When the code differs from the last compile the class must have been changed. Every class which has no dependencies in any way with the main class which extends from DragomeVisualActivity will be ignored by the parser.

Dragome compiler has two modes, one uses node reduction to achieve a high performance js code, and the second one is very similar to JVM execution mode to achieve highest compatibility execution.

Does the current implementation has that already? I found the CompilerType enum and wondered already what that means. It seems that another compiler looks it up when it is on strict. But i am not sure since i stopped debugging at some point.

It would be nice to make some tests around it, to see if it's a good choice to start a new compiler.

What kind of test do you mean?

Anyway you got some good points there on what a better compiler would need to replace the current solution. I will try to create some sheet about a good compiler architecture. I think one of the bigger / biggest problem is to create allow reflection support. Maybe you can write something that illustrate how exactly it works currently.