> where the generated assembly code by the JITs is checked by humans Is it? I have heard anecdotes that it is still slower than direct array usage, presumably due to the modCount tracking mechanism. Don't know if escape analysis and the resulting stack allocation in the compiled code eliminates that field.
________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of Remi Forax <fo...@univ-mlv.fr> Sent: Sunday, May 11, 2025 5:16 AM To: 임민수 <godmlz...@naver.com> Cc: core-libs-dev <core-libs-dev@openjdk.org> Subject: Re: Unnecessary logic is added to removeFirst and removeLast of ArrayList. Duplicating the logic is bad in some cases and not that bad in other cases. Here ArrayList is one of the most used class in Java (with String and HashMap), it is heavily optimized (to the point where the generated assembly code by the JITs is checked by humans), so duplicating the logic is not a bad idea, From a documentation POV, you do not have to jump through many methods if you want to see the implementation and in terms of performance, you want the inlining to be done by hand because the methods of ArrayList are usually deep in the call graph, so you may reach the inlining threshold right inside removeFirst(). In general, you do not optimize applications and libraries the same way. Usually, you do not optimize application code that often but for a library, if a lot of people are using it, it may worth to spend time to optimize for the benefit of everybody. regards, Rémi
