Performance testing Corda with the DJVM enabled has highlighted the following issues:
A very large amount of time initialising cryptography classes inside the sandbox in order to deserialise PublicKey objects. This is particularly serious because this work must be repeated inside every sandbox and it sends the JIT compiler into a tail-spin. However, this is best fixed from within the Corda node by patching a hand-written version of Corda’s Crypto object into the sandbox. This object will simply delegate operations to Corda’s Crypto object and so be much cheaper to create.
Lock contention in the AppClassLoader as concurrent sandboxes all try to load the same non-sandbox classes.
The DJVM is very hungry for JVM Metaspace. This part of memory needs to be garbage-collected more frequently. (This is an operational issue and does not require a code change.)
The creation of a large number of RuntimeCost$increment$1 objects. While these objects are probably garbage-collectable, it does suggest inefficiency in the cost accounting code.