On Tue, 24 May 2022 00:03:54 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> 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. I remember IDEs used to suggest using correctly sized arrays in the calls to `toArray`. Now they suggest using zero-sized array. My idea was to resolve the warning raised by the IDE to reduce the number of yellow highlights on the file outline. I agree the performance gain if any is negligible in this case: we don't expect many icons, probably no more than 3. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850
