What the heck is Project Loom and what can a normal Java developer expect from it? by Deepu K Sasidh

[@TJ-hs1qm]

19:49 Virtual threads use the heap instead of the stack, which is a major pain point of normal threads. The stack has a fixed size, while the heap can grow and shrink depending on how much memory is available. This means that virtual threads are less likely to cause memory problems than normal threads, especially when running a lot of threads at the same time.

[@kappaj01]

Sorry - but not highlighting details as to why we need this. OS Threads consume Memory - so you can have only so many on a server before you reach the limit. Now, if a thread is waiting for the DB server to return data, it is hogging memory which is now idle. This can be used for doing real work while the DB server is busy retrieving the data. So that is why we have reactive. So the OS Threads are now busy doing useful work instead of waiting for resource data being returned. With Loom you will not have to manage this complicated reactive pipelines. You simply continue using you SpringBoot MVC project. Now you will see your server CPU usage go way higher than previously possible.

[@codecoffee-farsi3392]

I am not sure if I got it correctly, creating a platform thread not only consumes more memory but also takes more time to create and switch. Also, in regard to DB, do you think we might still need to limit the number of max threads for the DB transactions like 20 - 25 threads per execution of db?

[@kappaj01]

@@codecoffee-farsi3392 Let me try again: Let's say we have a 12 core CPU - that means we can have a max 12 threads running concurrently. So new un MVC we spin up 200 threads under user load. So of the 200 only 12 can actively run. The rest as consuming memory while waiting for something to return data, capture input, etc. Wit WebFlux, Spring only spins up the same number of threads that we have cores for. Then based upon callback events it schedules the load to be processed. So now we will see much higher CPU usage, as all the cores are kept busy. So, with Loom we will see something similar. The JDK handling the thread scheduling of the virtual threads ontop of the actual threads. The link I posted really explains it really well. As to DB side - in my understanding we should be able to reduce the number of DB connections, as we don't have a connection sitting there waiting fo the data to be returned. The connection thread is only busy when it is transferring data. I'm doing a rather big service with AWS S3, R2DBC and full reactive SpringBoot stack. Can't wait to see this running under a bit of load! Big unknown at the moment. Hope this explains it better

[@avinashsingh93512]

Where can find the source code which is shown in demo? Please provide git repo link. Thanks :)

[@oneearthan]

He should not have told he says "aaaa" a lot. If he had not told that, it would be a normal talk. Once he said it, that is tuned in Audience to look for that, that is all that one can hear, making it unwatchable. It's like if I ask you, not to think of a Monkey, that's all you think about.

[@vers85]

Im not so happy about it. One of my main arguments to switch to kotlin that sells easily to the business is the performance of the coroutines. No one cares that the language is just way better than Java. Now there's an counterargument 😉

[@ArneBab]

Thank you for the nice demo!

[@ibrahim47]

Great talk

[@ashvinsharma97]

He was sure not kidding about his chronic tendency.

[@DF-ss5ep]

There's worse

[@leorandomnickname]

it would have been better not to reveal it to the audience because you immediatly start to notice it, its better just not to say anything.