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

[Sebastien Deleuze]

I see, make sense, thanks for the clarification.

On Wed, Feb 21, 2024 at 11:49 AM masoud parvari <masoud.parvari at gmail.com>
wrote:

> 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.
>
>

-- 
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/7feb711a/attachment-0001.htm>