Nu JVM Benchmarks
This area contains all information regarding the evaluation of our current implementation of the Nu JVM. Please check back often, as these results will be updated frequently as we make various improvements.
Three types of overhead have been identified regarding the implementation of Nu JVM. These are: dispatch, delegate invocation, and pattern matching. We will actively track the performance of our implementation with regard to these specific overheads.
Dispatch Overhead
This overhead appears due to the addition of code to perform dispatching. The dispatch code needs to call the matching code (if appropriate) and call the delegate invoke code (if appropriate). This code must run every time a join point executes, regardless of number of bound patterns.
Performance Goals
-
This overhead should be constant — independent of the number of patterns already bound.
Status: Success -
This overhead should be minimal — ideally zero.
Status: In-progress
Early implementations suffered from having to call the matcher every time a join point executed. The addition of caching improved this performance through remembering the previous match(es) and only performing matching as needed. Delegates associated with matched patterns are cached at each join point so the dispatch knows if it should call the delegate invocation code.
Benchmarks
Delegate Invocation Overhead
This overhead appears due to the need to invoke delegates at the execution of matched join points. At each executing join point, for each (currently) bound pattern that matches it, the associated delegate must be invoked.
Performance Goals
-
This overhead should be linear in the number of delegates needing invoked.
Status: Success -
This overhead should be comparable to the overhead of calling the delegate directly in the high-level language.
Status: Success
When a pattern is matched against a join point, if it matched then the associated delegate is cached at that join point. This allows the creation of a chain of delegates that can be efficiently iterated over and invoked.
Invocation is performed from inside the virtual machine. Information about the delegate needing invoked is already available (due to the previously mentioned caching) and the virtual machine simply has to invoke the delegate.
Benchmarks
Pattern Matching Overhead
This overhead appears due to the need to match bound patterns against join points. When each join point is executed, it must know which of the (currently) bound patterns matches it.
Performance Goals
-
This overhead should be minimal with zero bound patterns — ideally zero.
Status: Success -
This overhead should reasonably scale with the number of bound patterns.
Status: Success
To address the first goal, the matcher checks if the number of bound patterns is zero and if it is, stops.
Benchmarks
Bind/Remove Benchmarks
In addition to the overheads already mentioned, we measure the performance of the actual bind and remove calls. For static binding, this performance affects the start-up time of an application. For dynamic binding, this performance affects the execution of the program.
Performance Goals
-
This overhead should be constant — independent of the number of patterns already bound.
Status: Success -
This overhead should be minimal.
Status: In-progress
