Marcin Mielżyński lopx at
Wed Apr 30 16:56:50 PDT 2008

>> contains methods responsible for stack 
>> management/manipulation. 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 ?


More information about the hotspot-compiler-dev mailing list