EA builds with changes to object monitor implementation to avoid pinning with virtual threads

[masoud parvari]

Hi Sebastien,

I did load testing locally and ran the application through Intellij. The
way intellij runs the application falls into "java -cp
"all-paths-to-classes-and-dependencies" com.example.MyApplication" category.

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.

Kind regards,
Masoud



On Wed, Feb 21, 2024 at 10:04 AM Sebastien Deleuze <
sebastien.deleuze at broadcom.com> wrote:

> Hi,
>
> FYI I will shortly provide dedicated feedback on those object
> monitor changes with Spring applications.
>
> Masoud, could you please share how the Spring Boot application you are
> benchmarking is deployed?
>
> Executable JAR deployment ("java -jar application.jar") is known to
> provide sub-optimal performance while serving static resources (with or
> without virtual threads involved). If executable JAR is currently used, I
> would advise to follow recommendations from
> https://docs.spring.io/spring-boot/docs/current/reference/html/deployment.html#deployment.efficient.unpacking
> for using a production-ready deployment. If the application is already
> unpacked, could you please share what variant you are using ("java
> org.springframework.boot.loader.launch.JarLauncher" versus "java -cp
> "BOOT-INF/classes:BOOT-INF/lib/*" com.example.MyApplication")?
>
> For any virtual threads related benchmark, I would also recommend to use
> the latest Spring Boot 3.2+ release available with
> "spring.threads.virtual.enabled=true" configured. If you identify areas
> where some refinements could be made in a typical Spring Boot application,
> feel free to let me know.
>
> Best regards,
> Sébastien Deleuze
>
> On Sun, Feb 18, 2024 at 11:02 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 17/02/2024 12:32, masoud parvari wrote:
>> > Thanks Alan for the detailed explanation. This reminds me of Java 21
>> > deadlock scenarios when obtaining a lock both outside and inside a
>> > synchronized block by some number of threads greater than machine
>> > cores, could potentially cause deadlock.
>> >
>> > I still have one question though. This deadlock scenario (a burst of
>> > virtual threads at startup with a mix of class loading (which comes
>> > with pinning) and resource loading from the same JAR files) is not
>> > happening on 21 and latest 23-ea. I suspect because Forkjoinpool
>> > creates more thread to compensate for pinning? Would you please
>> > shed some light on this?
>> >
>>
>> In JDK 21, the two threads doing getResourceAstream (#119 and #123)
>> would not have released the carrier when they blocked on the monitor in
>> Zipfile.getEntry.  They pinned their carriers. With the EA builds, they
>> do release the underlying carrier threads to do other work. This just
>> means that other scheduled virtual threads get to run and block in
>> nl.trifork.qti.model.processing.expression.general.BaseValue.<init> with
>> a native frame on the stack. So with JDK 21, it was possible to exit the
>> monitor for the ZipFile and #119 or #123 would continue. With the EA
>> builds, neither can continue as there is no carrier available. This is
>> not your doing of course. BaseValue.<init> is probably resolving a
>> reference to a class and this is the call through the VM.
>>
>> I think the summary here is that addressing the issue with object
>> monitors pinning is great but the hoorays may be short lived as the spot
>> light moves to other cases where carriers are pinned, and specifically
>> native frames due to resolving references to classes in the constant
>> pool and the resulting class loading, or class initializers. There are
>> some ideas around this that may provide some relief on these cases. We
>> had to shake out issues with object monitors first.
>>
>> -Alan
>>
>>
>>
>>
>>
>>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240221/d30ed713/attachment.htm>