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

[Vladimir Kozlov]

This looks good. You need second review.

Thanks,
Vladimir

On 11/25/15 6:57 AM, Zoltán Majó wrote:
> 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
>