Question about using virtual thread

Attila Kelemen attila.kelemen85 at gmail.com
Tue Jun 27 22:12:18 UTC 2023


>
>
> To detect thread pinning, you might try:
>
> -Djdk.tracePinnedThreads=full
>
>
> This system property is documented in JEP 444:
>
> The system property jdk.tracePinnedThreads triggers a stack trace when a
> thread blocks while pinned. Running
> with -Djdk.tracePinnedThreads=full prints a complete stack trace when a
> thread blocks while pinned, highlighting native frames and frames holding
> monitors. Running with -Djdk.tracePinnedThreads=short limits the output to
> just the problematic frames.
>
> https://openjdk.org/jeps/444#Executing-virtual-threads
>
>
Thanks, this system property eluded me for some reason. Anyway, I have
checked the DB pools by enabling it, and they - with the exception of DBCP2
- don't report any pinning. Even DBCP2 only uses `synchronized` when
returning the connection to the pool (seems trivially fixable in DBCP2).

I have tried to check the Derby anomaly with it, but still a bit puzzled,
because it indeed seems to pin the thread always on `executeStatement`.
There is some trickery there with potentially using the same lock for
multiple connections, but I don't see why that would happen. That said, I
didn't read its code that thoroughly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230628/13e4520a/attachment.htm>


More information about the loom-dev mailing list