Review request for JDK-8007273

[Hannes Wallnoefer]

I followed Attila's suggestion to actually keep data in 
ScriptFunctionData for all functions. While the change is more involved 
than with the previous patch I think it's worth it: Field count in 
ScriptFunction is greatly reduced, constructors got even simpler, and 
ScriptFunction class as a whole got smaller and simpler since much of 
its static initalization code moved to ScriptFunctionData.

New patch is at http://cr.openjdk.java.net/~hannesw/8007273/webrev.01/

Hannes

Am 2013-02-04 11:11, schrieb Marcus Lagergren:
> +1.
>
> This is great. It made stuff simpler.
>
> Can you reconfirm the performance numbers (I understand you are doing that anyway). Won't most of the improvement be because of reuse of ScriptFunctionData at Function creation sites rather than lack of method handle adaptation. I like that we are as lazy as possible with modifying method handles too though, we've learnt that it does indeed matter.
>
> This should play nicely with my call site type specialization work.
>
> Attila brought up the the issue of deconstructing the ScriptFunctionData into fields in the ScriptFunction again, but I don't have any strong opinions about it. Deconstructing it may be unnecessary, but it buys some readability and not all constructors have access to ScriptFunctionData I guess.
>
> /M
>
> On Feb 4, 2013, at 10:14 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> Please review webrev for JDK-8007273 (Creation of ScriptFunctions can be refactored):
>>
>> http://cr.openjdk.java.net/~hannesw/8007273/
>>
>> This introduces a ScriptFunctionData class that stores everything needed to instantiate functions and is stored in a script class's constants array.
>>
>> It also adds a dedicated ScriptFunction constructors for functions from compiled code as opposed to other types of functions such as built-ins. This makes code simpler since different types of functions have different properties (e.g. built-ins don't have source or token, compiled functions don't have to compute arity from signature...).
>>
>> I also tried various forms of optimization and found the one thing that helps is to not adapt method handle signatures into something that can be used by used by ScriptFunction.invoke()/.construct() (which mainly means boxing the return value to Object) right away in the constructor. Instead the method handle is now left unchanged in ScriptFunction and only adapted lazily for invoke()/construct(). This seems to improve performance in earley-boyer and gbemu by something like 10-20%.
>>
>> Hannes