hand optimised methods

[hrj]

Background

I am trying to design a simple JIT compiler for doppio. During analysis, I noticed that for my benchmark, the following methods were the most frequently called:

count of calls: method name
------------------------------------
161516: java/lang/Math/min(II)I
147661: java/lang/Object/<init>()V
113636: com/sun/tools/javac/file/ZipFileIndex/get4ByteLittleEndian([BI)I
113633: com/sun/tools/javac/file/ZipFileIndex/access$500([BI)I
90974: com/sun/tools/javac/file/ZipFileIndex/get2ByteLittleEndian([BI)I
90962: com/sun/tools/javac/file/ZipFileIndex/access$400([BI)I
84696: java/lang/String/compareTo(Ljava/lang/String;)I
83489: com/sun/tools/javac/file/ZipFileIndex$Entry/compareTo(Ljava/lang/Object;)I, com/sun/tools/javac/file/ZipFileIndex$Entry/compareTo(Lcom/sun/tools/javac/f
ile/ZipFileIndex$Entry;)I 

Implementing the JIT compiler will take some time, but I thought I would hand-compile the above methods for two reasons:

• To see how much performance benefit it fetches.
• Some of these methods are too complex for the first iteration of JIT that I am planning. They have loops and branches that will take a long time to JIT optimise.

Changes

This PR adds some more "trapped methods" that help improve speed because they are implemented as native JS functions that use NativeStackFrame instead of interpreted methods with BytecodeStackFrame.

Benchmark result

For the "compile" benchmark:

Environment	Time before	Time after (improvement percent)
Chromium 48	26870	23327 (13.2)
Firefox 44	33796	29602 (11.6)

[hrj]

If this PR is acceptable, then further work can be:

• to add trapped implementation for all similar methods such as different Math.min and Math.max variants.
• remove the "simple" trapped methods after JIT is implemented. For example: com/sun/tools/javac/file/ZipFileIndex/get4ByteLittleEndian. These don't have branches or loops so JITing them is easy and has predictable tradeoffs (JIT overhead v/s performance improvement).

[jvilk]

I am not willing to add any additional trapped methods, even for speed. It adds additional maintenance burden that we should not attempt to bear. I would rather focus on improving the speed of the bytecode so that these aren't necessary.

If you want to surface an API to register custom trapped methods, I will merge in a PR for that feature, and you can continue to use hand-defined methods in your projects.

I hope your JIT works out! That would certainly be interesting to see. One speed issue with our bytecode interpreter is that we eagerly create stack frames, rather than create the stack frame lazily when it is needed to suspend / create an exception stack trace. Changing how that works is a serious undertaking, but may make it easier to implement a JIT.

[hrj]

I can understand your hesitancy to merge these changes in.

If you want to surface an API to register custom trapped methods, I will merge in a PR for that feature, and you can continue to use hand-defined methods in your projects.

That's a great idea; thanks! Adding it to my todo list.

I hope your JIT works out! That would certainly be interesting to see. One speed issue with our bytecode interpreter is that we eagerly create stack frames, rather than create the stack frame lazily when it is needed to suspend / create an exception stack trace. Changing how that works is a serious undertaking, but may make it easier to implement a JIT.

Is lazy creation of stack frames possible with the asynchronous-calling behaviour of doppio? #359 seems a bit relevant.

The JIT I am planning is very simple; in the first cut, it will just coalesce opcodes to avoid hammering the operand-stack, similar to the first point in #32. Control-flow opcodes (invokes, conditional jumps) will not be included in the JIT trace, atleast in the first cut. I am hoping to write a design document soon, to get your feedback.

[jvilk]

You'd have to change a lot to lazily create stack frames, but it is possible to do. I look forward to seeing your proposal!