Longjumps considered inexpensive...until they aren't

[Charles Oliver Nutter]

John Rose wrote:
> Are a lot of those (effectively) tail calls?  This will be more  
> common in dynamic languages, and we could tune the inline heuristics  
> to prefer to inline tail calls.

Some of them are, but the need to have pre/post call logic (like 
artificial call frames) means many/most of these calls will ultimately 
not be tail calls.

> We should probably also experiment with (gulp) an @Inline annotation  
> for methods, not to override the heuristics, but to add a vote from  
> the code writer.  It could be made Hotspot-specific, to start with.   
> (I have an annotation parser for the VM classloader, that will be in  
> my next post to the mlvm repo.)  For a gross, gross POC hack, the VM  
> could try putting looking for the string "_inline" in the method  
> name, and bias the inlining heuristic.  There is also a compiler  
> oracle function in the JVM which can be used to place advice on  
> individual methods, but it is hard to use and not modular (single  
> property file).

I have managed to eliminate one of the frames and simplify several 
others, with a subsequent perf boost in my simple JRuby nonlocal return 
benchmark (about 25% faster). It's still nowhere near as fast as the 
normal "falling out" return case though.

Another point that became obvious when logging compilation is that all 
our crufty overhead to support Ruby is probably using up the little 
capital we have to spend on inlining. For example, to maintain an 
accurate Ruby-land call trace, we need to update a separate line number 
counter. To support Ruby's unsafe Thread#kill and Thread#raise methods, 
we need to periodically checkpoint. And of course there's the artificial 
frame stack, which holds out-of-band data we can't easily pass through 
the Java call stack (and which still might not be available everywhere 
it's needed). All this ends up getting inlined, because it's fairly 
short paths...but it seems like it makes the total inlined result a lot 
"flatter", probably because the total size of inlined code gets puffed 
up a lot.

Exploration continues. I'm still looking for the magic bullet that will 
eliminate our need for artificial frames.

- Charlie