EA builds with changes to object monitor implementation to avoid pinning with virtual threads
Alan Bateman
Alan.Bateman at oracle.com
Thu Feb 22 12:08:55 UTC 2024
On 21/02/2024 10:49, masoud parvari wrote:
> :
>
> And of course I am aware of Spring Boot 3.2+ releases. The point of my
> load testing was testing an application with lots of contention on
> objectmonitors rather than a setup where most of the synchronized
> blocks have been replaced by ReentrantLock.
>
> So I would argue that for the mere purpose of testing Loom's new
> object monitor implementation, and making sure hanging is not
> happening, Spring boot 2.7.x is a better candidate than 3.2.x. I hope
> this helps to clarify the testing's goal.
>
I'm not familiar with the different versions of Spring but it sounds
like the 2.7.x has more uses of object monitors. That is useful to know.
Note that the EA builds have been refreshed to pick up recent changes
(and changes from main line). There is a change to the object monitor
implementation that makes blocked threads that are pinned compete with
the chosen successor when some thread exits a monitor. That should help
with some of the cases where resolving class references is calling
through the VM to load classes. Also one of your mails mentioned that
your JFR recordings didn't have all the expected jdk.VirtualThreadPinned
events. There are three cases where jdk.VirtualThreadPinned is recorded,
one of these missed the first EA build.
-Alan
More information about the loom-dev
mailing list