On Tue, 10 Jun 2025 02:26:22 GMT, Prasanta Sadhukhan <psadhuk...@openjdk.org> 
wrote:

> What condition? 

I just meant the int overflow condition. That test is not meant to demonstrate 
an OOM.

I understand why an OOM feels related to this ticket (and maybe that really is 
the compelling concern here), but I don't think that ticket mentioned memory 
consumption.

Here's a recording that (I think?) shows I reached the int overflow in about 15 
minutes:
https://go.screenpal.com/watch/cT16h0nX6xx

(You may need to look at the system clock in top-right to accurately track 
time; parts of the video are sped up 10x. It should be pretty clear when the 
text cursor blinks super fast.)

We could expand that test to:
A. use an animated gif, or 
B. try to load a new non-trivial image once we cross into a negative ID

... but that circles back around to the broader "what are we really trying to 
solve" question. (And I don't think I know the answer to that question.)

> This issue was not raised by me so clearly somebody felt the need for it.

Sure.

> Also, I think it is better to get ABORTED status for the image to let the 
> user know so that corrective action can be taken, instead of aborting the 
> application with OOM or whatever exception it gets thrown

OK. This feels too theoretical for me to invest strongly in a recommendation.

On the one hand: what you're saying makes sense, and obviously avoiding an OOM 
is a good thing to do.

On the other hand: if the integer overflow occurs in a non-trivial real-world 
usage: I'm guessing the images/icons already *are* actually being responsibly 
disposed of/garbage collected over time. So what we really need is to reset the 
counter or use a new MediaTracker if the int overflow condition is reached. For 
example, suppose we use all 2147483647 images IDs, and each image is 100x100px 
and 3 color channels. That's going to require about 60,000 GB of data (in terms 
of pixels). If those images are kept in memory, then we will reach an OOM long 
before we reach an integer overflow. So the fact that we get here (to the 
integer overflow) at all may (?) mean the application is responsibly discarding 
images and it's able to handle thousands more over time.

Most of all I'd like to see a real-world use case explaining how this impacts a 
user. Until then: this PR looks good/harmless (IMO).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2136974078

Reply via email to