Review request for http://cr.openjdk.java.net/~lagergren/8005976/webrev/

[Marcus Lagergren]

Fixed. Thanks, dude.

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

> - updateSymbolsLog() is only ever invoked with setScope==true
> - In Symbol.java, if you now have if() statements for checking whether setIsScope() and setSlot() will actually change any state for logging purposes, why not move the operations themselves into the conditional block?
> 
> These two minor things are all I have.
> 
> Attila.
> 
> On Jan 11, 2013, at 9:47 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
>> Can I get a review request for http://cr.openjdk.java.net/~lagergren/8005976/webrev/ please.
>> 
>> I've finally managed to break out Access Specialization (call site specialization) as an iterative phase inside code generator and put it after Lowering. 
>> 
>> The next step is to assign symbol types only after Lower and Access Specialization have been completed so constructs like 
>> 
>> var x ;
>> function f() {
>> var y = (x=55);
>> }
>> 
>> won't get object fields. y can be a local slot of type int, but right now Lower, before any scope analysis has taken places goes ahead and says "d'uh - this x - it's an Object". This has been the behavior since the beginning of time, before we started looking at individual callsites. Access Specializer then says "well, it's in scope, but at least you can specialize the callsite to an int" and then no one ever updates y. 
>> 
>> So I'm slowly starting to decouple these too conservative type analysis dependencies. This is because good call site type information is the absolute key for iterative/lazy jitting in the future execution model.
>> 
>> I've verified that we do more and not fewer call site specializations with this change (I checked in a previous version of this in November that was reverted becaus as the scope analysis was incorrect and the AccessSpecializer got a lot more conservative.) This is not a problem anymore with this change.
>> 
>> Also added some more compiler logging so we can see what the Compiler is doing in greater detail with --log=compile.
>> 
>> Test runs. Test 262 runs. Node.js tests run (at least as well good as tip does).
>> 
>> /M
>> '
>