Please review CR8009718 - lazy execution architecture continued

[Marcus Lagergren]

Thanks for the review.

* The commented code in coerce is there because we currently don't support changing types based on uses, only on definitions. We need some additional processing for that to work. I'll add a comment to explain. 

* Removed the commented code in Parser and the System.err

* Removed the comment in bindToCalleeIfNeeded and the System.err

When it comes to the naming scheme, I agree that "Invocation" is a bit too generic. However, it's not just a Specialization - it can be the only version of a method that exists. Specialization sort of implies that there are many versions, which need not be the case. Perhaps "Version" or some variety of that is better.

/M 


On Mar 11, 2013, at 10:21 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Mostly looks good - we worked on parts of it together few weeks ago. I mostly found small cleanup issues:
> 
> - commented code in Attr.coerce(BinaryNode, Type, Type)
> - Parser.java commented code and System.err
> - ScriptFunction.bindToCalleeIfNeeded() commented code;
> - ScriptFunction System.err.println
> 
> I like how the FinalScriptFunctionData/RecompilableScriptFunctionData/Invocation division of responsibilities turned out. I keep thinking we should find some better name for "invocation", though, it's starting to be such an overloaded term. "Specialization"? "FunctionHandles"? "FunctionHandlePair"? Something else?
> 
> Attila.
> 
> 
> On Mar 11, 2013, at 7:40 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
>> Reviews, anyone?
>> 
>> On Mar 8, 2013, at 10:42 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
>> 
>>> http://cr.openjdk.java.net/~lagergren/8009718
>>> 
>>> In order to truly turn this into method specialisation, I need Attila's copy-on-write cloning to work for object nodes, as right now a Compiler mutates its FunctionNode when the tiers are executed.
>>> 
>>> I removed the trampoline class and vastly simplified the creation of ScriptFunctions so that everything lives in the ScriptFunctionData and method handles and allocators are lazily resolved at runtime. The same thing happens when eagerly compiled functions - they are not resolved until requested. This makes lazy method compilation and specialization transparent to the runtime. It only knows it asks for code that may or may not be there.
>>> 
>>> Changed the model of "one method handle, potential specializations" to just be "this function has a collection of invokers - pick the one that fits using calltype".
>>> 
>>> /M
>>> 
>>> 
>> 
>