[9] RFR(M): 8129847: Compiling methods generated by Nashorn triggers high memory usage in C2

[Zoltán Majó]

Hi,


please review the patch for 8129847.

https://bugs.openjdk.java.net/browse/JDK-8129847

Problem: JDK-8014959 and JDK-8058148 have increased the value of the 
LiveNodeCountInliningCutoff and MaxNodeLimit thresholds. The thresholds 
closely affect the number of unique compiler nodes within compilations. 
As the size of many of the C2 compiler's data structures is proportional 
to the number of unique nodes, the changed thresholds increase the 
memory usage of the C2 compiler. In some cases (e.g., when compiling 
Nashorn-generated methods), the memory usage increases significantly.

Solution: This changeset proposes to add a new compiler phase, 
PhaseRenumberLive, that (1) identifies live nodes and then (2) assigns a 
new ID to each node. Each node is assigned a distinct Node IDs from the 
interval [0, x), where 'x' is the number of live nodes. 
PhaseRenumberLive updates the compiler's unique count to 'x'. Decreasing 
the compiler's count of unique nodes reduces the compiler's memory usage.

Webrev: I created a webrev for both 8u and 9 because the reproducer 
attached with the bug report runs only with 8u:
[9]: http://cr.openjdk.java.net/~zmajo/8129847-9/webrev.04/
[8u]: http://cr.openjdk.java.net/~zmajo/8129847-8u/webrev.04/

Testing:
- JPRT
- Octane/Nashorn

Evaluation:
- reduction of the number of unique nodes: see following table with top 
5 methods in reproducer (methods were ranked in decreasing order of 
their maximum unique count):
http://cr.openjdk.java.net/~zmajo/8129847-8u/node_count.html
- reduction of resident set size (RSS) of the VM: 39% with reproducer, 
5% on average with Octane/Nashorn;
- no performance regression (Octane/Nashorn, SPECjvm2008).

Thank you and best regards,


Zoltan