Please review CR8009718 - lazy execution architecture continued

[Jim Laskey (Oracle)]

Attr.java

comments?

1010     private Node coerce(final BinaryNode binaryNode, final Type operandType, final Type destType) {
1011         //newType(binaryNode.lhs().getSymbol(), operandType);
1012         //newType(binaryNode.rhs().getSymbol(), operandType);


Would it be better to return Type.OBJECT instead of null?

1250             Type type = functionNode.getSpecializedType(ident);
1251             if (type == null) {
1252                 type = Type.OBJECT;
1253             }


ScriptFunction.java

494         MethodHandle guard = null;
495 
496 //        System.err.println(data + " NEEDS CALLEE " + data.needsCallee());


InvocationList/SpecializedMethodChooser webrev is messed

+1



On 2013-03-11, at 10:33 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> Can I get another review, please?
> 
> /M
> 
> On Mar 11, 2013, at 10:45 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>