4 ms·

The value of loom, or fibers is essentially in creating a thread abstraction that performs comparably to an event loop. A common pattern in Java is to spin up X

The value of loom, or fibers is essentially in creating a thread abstraction that performs comparably to an event loop. A common pattern in Java is to spin up X threads to perform a blocking network operation. Or to have X threads each with a connection to a client. If you want a web server to process 50 requests concurrently, then having one request serving thread per core won’t cut it. These approaches of spinning up lots of Java threads are fine, until they aren’t, when you have too many threads. Loom is not a panacea and doesn’t make any new thing possible, it makes certain things easier. And it still will have its limitations.

vemv 5y ago
An informed thread-based approach is quite more careful than just spinning "lots of threads" and can certainly achieve a concurrency of 50, or 10000. Let's say we want a concurrency of 1000 and have 8 CPUs available. I'd have small thread pools, one per logical kind of task. Maybe this would result in 20 threads total for the whole JVM. Concurrency would be represented by the items being held in BlockingQueues of max size 1000. Items would be transferred from thread to thread by communicating via said queues (pipeline pattern). CPU utilization would be practically ideal as there's always a thread having some kind of work at hand. And the system would be actually concurrent since the queues can have interleaved workloads (e.g. work for users #1, #2, #1 again, #3, etc). The max queue size allows to communicate backpressure to e.g. a load balancer.
- hilbertseries 5y ago
  I don’t really follow the way you define terms here. Concurrently means processing at the same time, if work is held in a queue it’s not being processed. If you reduce the number of threads to 1 and leave the queue at 10k. You’re claiming that this is concurrently processing 10k messages, but you only have one thread. Is the idea here that you’ve reimplemented scheduling on top of the jvm? This is exactly what project loom is trying to protect the developer from having to do.
  - vemv 5y ago
    As long as there's more than 1 thread processing the queue, the queue is being concurrently processed. Particularly, the queue items will be picked up in a nondeterministic order, driven by CPU utilization. > Is the idea here that you’ve reimplemented scheduling on top of the jvm? No, I'm implementing a fairly vanilla pipeline pattern, just with simpler, more explicit blocks than those used by async frameworks/abstractions. IIRC it's described well in the JCIP book.
    - closeparen 5y ago
      It sounds like you're talking about a CPU-heavy workload. In this context often it's an IO-bound workload; the service makes upstream requests to a database and other services. Most of the request lifetime is waiting for responses. To get reasonably many requests started and waiting on those responses, either you need to write in async/callback oriented style, or you need a mechanism to make many thousands of naive, blocking routines coexist efficiently.

vemv 5y ago

An informed thread-based approach is quite more careful than just spinning "lots of threads" and can certainly achieve a concurrency of 50, or 10000. Let's say we want a concurrency of 1000 and have 8 CPUs available. I'd have small thread pools, one per logical kind of task. Maybe this would result in 20 threads total for the whole JVM. Concurrency would be represented by the items being held in BlockingQueues of max size 1000. Items would be transferred from thread to thread by communicating via said queues (pipeline pattern). CPU utilization would be practically ideal as there's always a thread having some kind of work at hand. And the system would be actually concurrent since the queues can have interleaved workloads (e.g. work for users #1, #2, #1 again, #3, etc). The max queue size allows to communicate backpressure to e.g. a load balancer.

hilbertseries 5y ago
I don’t really follow the way you define terms here. Concurrently means processing at the same time, if work is held in a queue it’s not being processed. If you reduce the number of threads to 1 and leave the queue at 10k. You’re claiming that this is concurrently processing 10k messages, but you only have one thread. Is the idea here that you’ve reimplemented scheduling on top of the jvm? This is exactly what project loom is trying to protect the developer from having to do.
- vemv 5y ago
  As long as there's more than 1 thread processing the queue, the queue is being concurrently processed. Particularly, the queue items will be picked up in a nondeterministic order, driven by CPU utilization. > Is the idea here that you’ve reimplemented scheduling on top of the jvm? No, I'm implementing a fairly vanilla pipeline pattern, just with simpler, more explicit blocks than those used by async frameworks/abstractions. IIRC it's described well in the JCIP book.
  - closeparen 5y ago
    It sounds like you're talking about a CPU-heavy workload. In this context often it's an IO-bound workload; the service makes upstream requests to a database and other services. Most of the request lifetime is waiting for responses. To get reasonably many requests started and waiting on those responses, either you need to write in async/callback oriented style, or you need a mechanism to make many thousands of naive, blocking routines coexist efficiently.