3 ms·

Some quick questions: - are you using an already-existing HTTP engine, like Jetty or Tomcat? - how do virtual threads fit into a web framework? - do virtual t

Some quick questions: - are you using an already-existing HTTP engine, like Jetty or Tomcat? - how do virtual threads fit into a web framework? - do virtual threads make debugging more difficult? (A more general JVM question, I suppose) - any performance / readability benefit, or just a coolness factor?

tipsee 4y ago
are you using an already-existing HTTP engine, like Jetty or Tomcat? Yes, Javalin is built on top of Jetty. - how do virtual threads fit into a web framework? Most JVM web frameworks (Jetty included) have a thread based request lifecyle (one thread handles one request from beginning to end). The java.lang.Threads are extremely expensive (~1mb memory), while Virtual Threads are very cheap (~0mb memory). We also have another ThreadPool for JSON streaming, and one for writing async responses. Using Virtual Threads for these things reduces overall memory pressure. - do virtual threads make debugging more difficult? (A more general JVM question, I suppose) Not that I know, but I've never used this in production myself. - any performance / readability benefit, or just a coolness factor? The alternative here is java.lang.Threads, so primarily the memory footprint. There is no readability difference. When developing, you don't see this at all.
rkalla 4y ago
Nothing to do with the project, but I read through it, so... 1. It's built natively on Jetty - very tight integration, not just some libs running in a Jetty container. 2. Web is inherently Request/Response - all of this can be handled with dramatically less resource requirements using Virtual Threads. Web is sort of the absolutely-best-use-case for Virtual Threads where as a Game Engine would be the opposite of that (one critical rendering thread and MAYBE a few extra long-lived threads for processing physics, audio, etc.) 3. I haven't tried debugging a Loom project but it's been in incubation for just under 100 years so I have to imagine this has been figured out. 4. About twice the throughput and 1/2 the latency of full OS threads - https://github.com/ebarlas/project-loom-comparison https://github.com/ebarlas/project-loom-comparison

tipsee 4y ago

are you using an already-existing HTTP engine, like Jetty or Tomcat? Yes, Javalin is built on top of Jetty. - how do virtual threads fit into a web framework? Most JVM web frameworks (Jetty included) have a thread based request lifecyle (one thread handles one request from beginning to end). The java.lang.Threads are extremely expensive (~1mb memory), while Virtual Threads are very cheap (~0mb memory). We also have another ThreadPool for JSON streaming, and one for writing async responses. Using Virtual Threads for these things reduces overall memory pressure. - do virtual threads make debugging more difficult? (A more general JVM question, I suppose) Not that I know, but I've never used this in production myself. - any performance / readability benefit, or just a coolness factor? The alternative here is java.lang.Threads, so primarily the memory footprint. There is no readability difference. When developing, you don't see this at all.

rkalla 4y ago

Nothing to do with the project, but I read through it, so... 1. It's built natively on Jetty - very tight integration, not just some libs running in a Jetty container. 2. Web is inherently Request/Response - all of this can be handled with dramatically less resource requirements using Virtual Threads. Web is sort of the absolutely-best-use-case for Virtual Threads where as a Game Engine would be the opposite of that (one critical rendering thread and MAYBE a few extra long-lived threads for processing physics, audio, etc.) 3. I haven't tried debugging a Loom project but it's been in incubation for just under 100 years so I have to imagine this has been figured out. 4. About twice the throughput and 1/2 the latency of full OS threads - https://github.com/ebarlas/project-loom-comparison https://github.com/ebarlas/project-loom-comparison