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

[Filipp Zhinkin]

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
initialization.

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):

http://cr.openjdk.java.net/~fzhinkin/growableArrayInitialization/webrev/

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,
Filipp

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