Introductions

[Marcin Mielżyński]

>> StackMachnie.java contains methods responsible for stack 
>> management/manipulation. ByteCodeMachine.java is the actual bytecode 
>> interpreter implementation (with matchAt method containing the big 
>> switch). Each opcode is implemented as a separate method.
>
> That is reasonable.  It keeps the switch per se small, and 
> (implicitly) asks the JVM to inline the opcode methods that really 
> matter.
>
Ah, forgot to mention this one. Surprisingly, removing unused cases (for 
given matches) that contain just method invocations affects performance. 
Can such slight differences in method size affect performance as well ?
Is that because of inlining/thresolds artifacts ? It there a possibility 
that neighbour method size plus the size of method being trimmed were on 
the verge of inlining threshold at hight level ?

Marcin