Hey Guys, I've been working on the right ValueHolder interfaces to avoid object allocation inside evaluation loops. It's easy when we're dealing with primitives but becomes more sticky when we're dealing with complex types like strings. There are two reasons I'm focused on this. The first is stack allocation. The second is scalar replacement. Stack allocation seems to work very well. However, scalar replacement seems slightly less reliable. I basically modeled three things we'll be doing:
- Simple method (with alloc and without -- the current runtime evaluation already using this alloc approach) - Set (one using multiple parameters, the other using a single object that contained primitives) - Get (one using multiple methods, one using a passed in object that is then populated, the third creating an object inside the get method and returning that object) I had been hoping that the latest JRE was smart enough to do scalar replacements across a single method boundary. It looks like it works in most cases. Strangely, it doesn't seem to work correctly in the set(Object) method. That said, it doesn't seem like that big of a deal and just leads me to think that this should be done with multiple parameters on the ValueVector.Accessor's. Thoughts? I didn't spend a lot of time trying to make this a super accurate benchmark so let me know if you think there are holes in my benchmark? Jacques ----- gist: https://gist.github.com/jacques-n/6096934 ====With Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions -XX:MaxDirectMemorySize=4G) initial noalloc alloc ret alloc method 523 538 set 593 788 get 425 558 424 warmed up noalloc alloc ret alloc method 336 337 set 261 630 get 406 379 402 ====No Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions -XX:MaxDirectMemorySize=4G -XX:-DoEscapeAnalysis) initial noalloc alloc ret alloc method 532 3982 set 619 1850 get 429 1985 2096 warmed up noalloc alloc ret alloc method 337 3546 set 299 1817 get 414 2133 2038 Run leveraging Oracle JRE 7u25 on a 2.3ghz 2012 Macbook Pro.
