RFR (L): 8149374: Replace C1-specific collection classes with universal collection classes
filipp.zhinkin at gmail.com
Tue Mar 29 14:20:51 UTC 2016
On Fri, Mar 11, 2016 at 2:42 PM, Filipp Zhinkin
<filipp.zhinkin at gmail.com> wrote:
> 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 . 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,
>  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