javax.imageio.ImageIO ThreadLocal use

[Duncan Gittins]

Alan

thanks for the information. I'll wipe my allowSetThreadLocal calls and add
-Djdk.traceVirtualThreadLocals=true to monitor this from JDK21+.

Unfortunately I'm not an expert on ImageIO - my observations (not backed
with solid JMH stats) are that JPG loading is quite slow, disabling caching
"ImageIO.setUseCache(false);" strangely appears to make it faster, and for
the NAS/USB storage devices I have it seems that preloading a whole file
into memory before calling Image.read(InputStream) beats Image.read(File)
directly. Not an issue for loom-dev, and I may be incorrect anyway.

Kind regards

Duncan

On Tue, 9 May 2023 at 19:01, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
>
> On 09/05/2023 18:46, Duncan Gittins wrote:
> > :
> >
> > I happened to be stripping out all my ThreadLocal code recently, and
> > so decided to check this work by adding "allowSetThreadLocals(false)"
> > onto all virtual thread builders to disable ThreadLocal use.
>
> We decided not to make allowSetThreadLocals a permanent API so it has
> been removed for Java 21. JEP 444 [1] provides a bit on the reasons for
> this.
>
> We haven't discussed the TL usage in the image I/O area here. Most of
> the effort on reducing usages of TL has been in the base/core area. If
> you have proposals/ideas for reducing the usage in the image I/O code
> then it would be good to bring them to client-libs-dev? If the TLs are
> for caching purposes then it's good to create some benchmarks to see if
> the caching helps or makes things worse.
>
> -Alan
>
> [1] https://openjdk.org/jeps/444
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230509/b914bc13/attachment-0001.htm>