RFR (L): 8149374: Replace C1-specific collection classes with universal collection classes

Filipp Zhinkin filipp.zhinkin at gmail.com
Fri Mar 11 11:42:40 UTC 2016

Hi all,

please review a fix for JDK-8149374:

Webrev: http://cr.openjdk.java.net/~fzhinkin/8149374/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8149374
Testing done: hotspot_all tests + CTW

I've replaced all usages of collections defined via define_array and
define_stack macros with GrowableArray.

There are good and bad news regarding performance impact of that change.
Unfortunately, C1 compilation time for CTW-scenario w/ release bits
increased from 51.07±0.28s to 52.99±0.23s (it's about 3.5%).

Such difference caused by eager initialization of GrowableArray's
backing array elements [1]. I can imagine when we actually need to force
initialization and de-initialization during array's
growing/destruction, but for some types like c++ primitive types or
pointers such initialization does not make much sense, because
GrowableArray is not allowing to access an element which was not
explicitly placed inside of it. And as long as GrowableArray most
widely used to store pointers we're simply wasting the time with

I've measured CTW time with following workaround which implements
initialization for numeric types and pointers as no-op and C1
compilation time returned back to values that were measured before
original change (51.06±0.24s):


I've also measured C2 compilation time and it dropped down by a few
seconds too: 1138±9s w/o GrowableArray's change and 1132±5s w/ it.

Summing up: I guess we should avoid GrowableArray's backing array
initialization for some types, don't we?

Best regards,

[1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/323b8370b0f6/src/share/vm/utilities/growableArray.hpp#l165

More information about the hotspot-compiler-dev mailing list