Please review JDK-8013914 - line number footprint

[Marcus Lagergren]

I've uploaded a new web rev. This one revealed some issues that just "happened to work" in tip, and some that didn't.

-debug-line=false, i.e. turning off line numbers, broke all over the code base. Apparently we don't have unit tests for that. I'll add one

The other problem was that explicit LineNumberNodes always created jdk.nashorn.internal.ir.Labels that created an evaluation stack just just conveniently happened to be around for dead code, such as 


break;
linenumbernode;
print("never written")

Removing the explicit line number node, broke CodeGenerator when it got to the dead code.

Of course, the code generation shouldn't even HAVE that dead code in the first place, so I had to change Lower, where it picks out variable declarations during statement placement in any block to ONLY pick out variable declarations, by going deep into the nodes past the terminator node. 

All tests pass now.

New web rev at: 
http://cr.openjdk.java.net/~lagergren/8013914/webrev.02/



/M

On May 6, 2013, at 6:08 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> I've introduced the Statement node, which proved to be a design advantage from other points of view as well - a Statement being the only kind of node that results in steppable code on the root level. Currently the Statement holds line number information and line number nodes are deprecated.
> 
> Line number nodes were brittle for several reasons 1) footprint 2) code moves around and they may not apply anymore, being loosely coupled instead of tightly coupled to code.
> 
> The next logical step is probably to move location information down into Statement, save memory for Node instances that don't need it. IdentNode needs it though, as we all know "x" in JavaScript may very well be a getter.
> 
> This fix saved quite a lot of IR footprint for large IRs. 
> 
> (I also slightly tweaked the heuristic for snapshotting parsed IR, so we don't save all IR all the time in case of future recompilation).
> 
> All in all I got the IR footprint of Octane Mandrel down by almost 30% with this fix combined with  JDK-8013913
> 
> http://cr.openjdk.java.net/~lagergren/8013914/
> 
> /M