On Mon, 23 May 2022 21:11:34 GMT, Phil Race <p...@openjdk.org> wrote:
>> We probably can extract this to the separate cleanup, the resulted code is >> smaller and faster. >> PS I have added a link to my previous message, accidentally hit submit >> button. > > I'm sure I've used this pattern > return icons.toArray(EMPTY_TRAY_ARRAY); > in code that runs often and may be performance sensitive, so I don't see > anything weird about it. > OTOH I am not sure this code is anything that needs super-optimising .. we > seem to have gone down that discussion route because it was the justification > for the change. > > BTW the shiplev article, which I skimmed must be suggesting that the array > initialisation must be faster if it is on the array it allocates itself > because of the APIs used .. but as he also notes things can change. > > Anyway this is mildly interesting discussion but no one will ever, ever be > able to measure a difference when it used here since it is probably 0.0001 % > of the work ... It also has a functional implication, in the old code the "size" on a Vector is called outside of the lock. So the resulted array after "icons.toArray" can be bigger than the number of icons. This is similar to this: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/classes/javax/sound/midi/Sequence.java#L281 I think that race can even be triggered by the new test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850
