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

[Vladimir Kozlov]

Including Filipp on CC list.

Vladimir

On 3/29/16 3:18 PM, Vladimir Kozlov wrote:
> Nice clean up but I don't see any source code removed. What benefits we have then?
> I understand that we don't generate subclasses for ResourceArray and use GrowableArray. But it will not save space I think.
> What prevents us to remove ResourceArray at all?
>
> On 3/11/16 3:42 AM, Filipp Zhinkin 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%).
>
> It is acceptable regression I think. I don't think we should optimize and make more complex GrowableArray just to save
> 0.5% of performance for C2.
>
> Thanks,
> Vladimir
>
>>
>> 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
>>