The JEP Café and the Inside Java Newscast were the best ideas for Java since introducing Lambdas.

@JosePaumard

2 жыл бұрын

Waow! Lambdas! That's something! Thank you!

Look at this amazing community, Java Community.

We love code please continue

what a wonderful, informative, and insightful video, thank you 😊

Yes, Please. We want video on structured concurrency

I just discovered JEP Café. Omg... subscribed.

@java

10 ай бұрын

👍 enjoy... and feel free to spread the word!

Great video! Looking forward to the Structured Concurrency video.

Nice presentation. The way you showed the JDK code increased my interest. I am going to do the same in my local. Thanks

Very insightful session !! Thanks !!

Thanks. Always a pleasure enjoying my coffee here.

Great video, it would be good if you can make more videos on these topics!

@JosePaumard

2 жыл бұрын

Thanks, will do!

Would like more on structured concurrency and its future plans. Fantastic video

@MyImprov

2 жыл бұрын

Same here!

Awesome! Thank you very much José.

@java

Жыл бұрын

Glad you liked it!

Excellent video, thanks!

Un grand merci! I would love to see more about how Java uses virtual threads to make async programming easier! 🥰

As usual another great video by Mr. Paumard. Please make such videos more frequently.

@JosePaumard

2 жыл бұрын

Thank you, I really appreciate it! -- José

thanks for sharing! very clear

Reminds me of Erlang/Elixir. Great to see something similar in Java.

Project Loom is blessing... now how the industry will replace reactive programming with Loom? so eager about it.

This was just amazing. Looking forward to more of such talks.

Great video! Thanks! I would love another video about Structured Concurrency.

Great explanation of Virtual Threads. If we could get more of the same with links to the code - that would be great. Thanks for a great presentation

Very informative examples, great presentation. Keep it up. Thanks for publishing! Java is awesome 👍

@JosePaumard

2 жыл бұрын

It is indeed! Thank you!

finally JEP cafe with some code hands on🔥

Wow, this is marvelous! Thanks!

Thank you, waiting for the structured programming talk !

Nice video, looking forward to next one

Please, do talk about Structured Concurrency, looking forward to it

Thank you, it's great video and I want to see Structure Concurrency next time too.

Excellent episode every comfy.

Great video!

太棒了！希望Loom在正式发布后能让整个Java生态发生质的变化，让我们在性能和其他方面与其他新生语言一较高下！

I love simple explanation on complex topics like this. Thank you for your time and efforts to provide understandable piece of knowledge! Can't wait for the next topic. Btw, I was also drinking coffee while watching this.

@Gennys

Жыл бұрын

I recommend watching some videos by Brian Goetz about the JVM and other java subjects if you like to dive deep into these kinds of things as well.

Please do video on Structured concurrency.

@JosePaumard

2 жыл бұрын

Will do!

Awesome, nice work

The yield-resume sounds like a safe version of stopping and resuming a thread, pretty cool

Amazing!

Great video, as always

Great presentation José!

Thanks 👍

Excellent content and so well explained; thank you, @José Paumard

Merci just as amazing as loom

Thanks a lot Great Video

Excellent presentation 👏

Amazing content!

Thanks you a lot!

Merci !

Amazing 👏!!!

@JosePaumard

2 жыл бұрын

Thanks!

it's very interesting

1:23 Great video! To be fair, these comments drive the Reactive community crazy. They have questions/concerns about virtual threads, and the Java team have responses in return. As one brief example: if you use 1000s of virtual threads which call an external service, then this can swamp the external service. The Java team counters with "well, use semaphores to protect resources". That's fine, but illustrates there is more nuance here than at first glance.

@udadog

2 жыл бұрын

They also said that there are instances where you would want to use traditional threads. Would it not be better to just use a thread pool for the example you gave?

@michaeleaster1815

2 жыл бұрын

@@udadog Ron Pressler (lead for Loom) has mentioned the semaphore idiom in his videos. I don't think one would want a platform thread, because if the task does other blocking operations (aside from call to external service), we would want that to be virtual. A platform thread would be overkill.

@thurstonn9210

Жыл бұрын

There is nothing in async/reactive programming that limits code from "overwhelming" an external service Virtual threads address a common desire, I want to get the better *efficiency* of using non-blocking IO (in reality, on sockets), without writing async-style (callbacks) code This has been available in Erlang like forever, and Go - the code looks sequential (i prefer that term to "blocking" or "synchronous"), but the runtime is using non-blocking IO under the covers Now, it's true that since it doesn't make sense to manage a pool of virtual threads, one of the side effects of a traditional thread pool is that it can serve to throttle demand (e.g. if a thread pool is designed to only execute code that consumes the external service), although of course this is not the purpose of a thread pool per se; now, if you want to throttle demand against an external service using virtual threads you will need some other mechanism (e.g. semaphores) The claim is pretty simple: if you want to : a. get the efficiency benefits of using non-blocking (socket) IO and b. write traditional sequential code (byte[] b = socket.read(2048)) you can do so in Java now using virtual threads this has been proven to work in other languages (look at the benchmarks for Erlang and Go TCP servers) for a long period of time The "Reactive community" had better get used to the idea that their java frameworks will face extinction (assuming the virtual thread implementation is stable and efficient); this is called progress

Java 1.8, I love it, it is the source of my income.

Very interesting! I like seeing the code, it helps a lot. Could we create JavaScript-like or Python-like generator functions using Continuations?

Super....

I love the cup.

Thanks, very informative. :) Where do I find the fancy regular expressions from @12:20? (or: What would be reasonable?) Thanks.

very informative video and he made it easy to understand this topic. loved this JEP Café series. BTW, from where we can buy this Java coffee cup? 🙂

Hi Jose, Could you please share us a code example?

Is there anywhere I can get the live demo?

Hi! Great video really! Does intellij 2022.2 ea support jdk 19 already?

How does Loom impacts some JIT performance optimizations like Escape Analysis? If I understood correctly, if Loom moves the stack to heap, EA doing stack allocations became not so useful, doesn't it? (but it is still very useful for hot-paths with non-blocking)

Can i use Virtual Thread in all case? Is there any case where i cannot (should not) use Virtual Threads?

Can you, please, tell me, if the implementation of Java virtual streams can compete with Erlang?

Do virtual threads support thread locals?

@JosePaumard

2 жыл бұрын

They do. But you the prefered pattern is to use ExtentLocal.

If you have a lot of virtual threads that yield at the same time (i.e. the stack is copied from the pthread to the heap), the heap memory might become overloaded isn't it ?

One of the problems with multithreading asides the cost of blocking is the risk of deadlocks, or livelocks as well as issues with shared memory thread safety. Does loom have an opinion around the paradigm for multithread like CSP

@tanveerhasan2382

2 жыл бұрын

What's CSP

@igboman2860

2 жыл бұрын

Communicating Sequential Processes (CSP)

Wow! that Continuation is very useful, also the cpu probably has an 8 cores that's why there are only 9 platform thread.

@unbekannter_Nutzer

Жыл бұрын

At 12:40, you can read "12 cores".

Its good approach to use virtual threads for multiple requests to database ? In particular thread will be call and mapping results (Its hard to split , because I use Spring Boot NamedParameterJdbcTemplate. Can you give me advice - I use Java 21 ?

my God!!!!

How do I access continuations? I added the OpenJDK 20 with loom, but I don't have access to jdk.internal where continuations are

@JosePaumard

2 жыл бұрын

You need to add this when you compile and run your code: --enable-preview --add-exports java.base/jdk.internal.vm=ALL-UNNAMED. Do not do that in production though.

Can someone elaborate the virtual thread getting pinned to a platform thread issue?

Can you self host the tunnel server?

where can I get that cup please?

1:13 I started learning reactive programming yesterday and found it bit difficult to understand.

Please show us structured concurrency

Source code reference would be good.

So, memory is not a limiting factor on how threads I can instantiate... I was thinking it is one of the factors since stack takes memory... If we can instantiate 10Mill threads, at least memory is not a factor... Of course context switch by OS cannot be a cost as well since even virtual threads are doing their own context-switch by swapping over stacks... So, net net I am lost as to where the benefits are coming from... Is it OS process table size that limits max platform threads?.. Also, on a lighter note, I guess Java 1.2 (or 1.3) only had green threads. If my memory is right only starting 1.4 they mapped threads to actual OS threads. So, did we go back in capabilities and getting there again only now.. after what - i dont know - 20 years?

@guilhermealvessilveira8938

2 жыл бұрын

No man. It's about not blocking kernel threads, when making IO calls.

@premkumaru

2 жыл бұрын

@@guilhermealvessilveira8938 Threads regardless whether they are virtual or real will block on IO. Is the process scheduling by JVM cheaper than what is being done by kernel?.. I want really understand where the benefits are coming from.

@guilhermealvessilveira8938

2 жыл бұрын

@@premkumaru Well, they refactor the old IO to be non-blocking when you use virtual threads, it's looks like it's blocking, but it's not blocking. Wheh he say that it's blocking the virtual thread in the IO call, the virtual thread is suspended, but the kernel threads continue it's executions. Do you know event loop? It's almost the same, where the kernel threads check if the virtual thread block, if it's blocked, he get the next virtual thread. If you look deeply, you will see that the virtual thread is a data structure, where it has the context being executed, the stack and other necessary information, it's not the same as kernel thread, where it is scheduled by the operating system to execute. In the example above, you can have almost the same performance if you use the classic event loop, but it's hard to program using event loop, not so hard, but, it's hard to debug, because the execution don't look one after another, it's a mess to debug this kind of application. One of classicals non-blocking IO is the Java NIO ServerSocketChannel and SocketChannel with the Selector. But, with fiber threads, they hide that complexity, and in it's core is non-blocking, when executing bound IO (not when you execute CPU Bound, like matrix multiplication, any type of calculation). Sorry for the long text.

@premkumaru

2 жыл бұрын

@@guilhermealvessilveira8938 Hi, I started googling and it landed me in stack overflow... I find that biggest factors arre: 1. no need to enter and exit protected mode for context switches ... (makes tonne of sense to me as they are super expensive) 2. OSes cannot optimise for the target language. Some are saying the stack can be much smaller in green threads and can grow as needed. 3. OSes need to do lots of checks as access could be across processes 4. Some points about setup and teardown costs... but that is addressed using Thread pools. In fact it is cheap to create and destroy virtual threads. (may be this is the end of thread-pools) Yeah, block and ready state transitions need not go to kernel (need not cross protection level gates) regardless of whether it is IO or just sleep. Event driven or Async can be difficult to understand and develop. It breaks the flow. You cannot break the flow like say, initiate IO and setup a callback to run when it completes. This model is painful and clearly virtual threads arre helping us keep it as close to imperative... Thinking of my other point regarding green threads in 1.3, I remember those days even Linux did not have support for threads. I think Windows did. So, when java subsequently mapped Threads to OS/Platform threads, I guess it got a lot better in terms of performance. I guess may be for the first time they got pre-emptive! That's another interesting point: Are virtual threads pre-emptive?.. I don't think they. are. It would be nice to get a confirmation. Getting back, I think we got the best out of OS/Platform threads and we are all the way the other side and we are correcting back a bit. It is actually amazing to see this evolution.. (in a hurry now.. sorry about going all over.. will think through and post more if needed)

@premkumaru

2 жыл бұрын

Just wanted to add this.. did not use NIO much.. but I have used select() system call... to wait on multiple IO targets. This model ends up to be event driven and logic does not flow naturally.

Baseeed

Don't understand why you need to call thread.join() ? When a thread is not a deamon thread, it should prevent the jvm from exiting. Strangely, when I start a virtual thread without calling the join method, the jvm exit without waiting for the vthread to process its task.

Virtual Threads it's ... something like Coroutines in Kotlin?

@rajivkumar-ub6uj

2 жыл бұрын

Yes

@JosePaumard

2 жыл бұрын

Nope. Moving the stack to the heap is only in Loom.

Loom has some drawbacks for instance these light threads are allocated on heap... ;(

With unlimited ram lol

I m get angry when watch this video, why not show all the code?

Oracle is only the reason why Java is losing its fame so rapidly despite these brilliant features. Look at this boring video! looks like it'd been recorded in the mid 90's. Who the hell uses daylight mode writing code in 2024!

Windows 🤮🤮

3:52 It put a smile on my face to see my good old friend "Unsafe.getUnsafe()". It's enormous power and importants in fast library's is undeniable. Despite the fact that it's not meant to be used. It's powers simply cannot be expressed in Java concepts and classes because of it's unsafe nature. The unpredictable results if not used properly make it dangerous. My opinion : The only way to implement it's functionality into java without being unsafe is to give up. Java should go the rust way and say "here you can have that dangerous tool. But it's your responsibility to use it correctly.". By giving the dangerous operation a keyword and a block / function you can contain the dangers in a concise space and discouraging people from writing simple wrapper to access the dangerous functions in an uncontrolled pseudo safe way.

OpenJDK 19.0.1, the 100 000 virtual threads consume ~100MB memory (profiler shows 100MB for jdk.internal.vm.StackChunk). Anybody knows why? Is Loom not ready, I thought it's supposed to consume very little memory? Now it consumes even more than platform threads.

Look at this amazing community, Java Community.