Hello Eirik, this is a general problem caused by type profile pollution in bytecode of these constructors so that virtual calls become slow, fully virtual calls. I do not think this site is used frequent enough that warrants a monkey patch like that in ArrayList; such monkey patches will be removed in the future shall the JVM provide a better specialization solution.
If you want to learn more about how type profile pollution works, feel free to check out the patch for https://bugs.openjdk.org/browse/JDK-8366424, where there's a benchmark that explains how all these pollutions happen. Regards, Chen Liang ________________________________ From: core-libs-dev <[email protected]> on behalf of Eirik Bjørsnøs <[email protected]> Sent: Wednesday, February 25, 2026 9:08 AM To: core-libs-dev <[email protected]> Subject: [External] : RFD: Specializing ArrayDeque copy constructor for ArrayDeque (and possibly ArrayList) Hi, While looking into ArrayDeque: : addElements recently, I noticed that the copy constructor ArrayDeque(Collection) does not specialize for an ArrayDeque being passed in a similar fashion to what ArrayList does. By utilizing the ArrayListBulkOpsBenchmark Hi, While looking into ArrayDeque::addElements recently, I noticed that the copy constructor ArrayDeque(Collection) does not specialize for an ArrayDeque being passed in a similar fashion to what ArrayList does. By utilizing the ArrayListBulkOpsBenchmark and adopting it for ArrayDeque, I was able to test the performance impact of specializing ArrayDeque(Collection) for ArrayDeque. Results show a reduction in time/op ranging from 30% (1 element) to 75% (75 elements). I also experimented with a similar specialization for ArrayList which shows promising results, up to 50% faster for lists of size 75. However, there are many collections in the JDK and which combinations to specialize for is not obvious. Is further exploration here worthwhile? Cheers, Eirik.
