quasar

In Quasar[1] -- a library that adds true fibers (just like Go's goroutines) to the JVM -- we've decided to go with copying stacks as well (this is the current, and original, implementation). Of course, Java doesn't have pointers into the stack, so there's no need to fix any pointers when copying, and the implementation can be in pure Java. [1]: https://github.com/puniverse/quasar

https://github.com/puniverse/quasar looks pretty nice, assuming you can't use erlang for whatever reason.

You might want to check out Quasar. (https://github.com/puniverse/quasar) While it might not be something built into Kotlin, I would assume that Kotlin's interop with Java would make it easy to use. There's also a library called Pulsar for Clojure that wraps Quasar nicely. (written by the developers who are making Quasar)

> And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps. Not quite. Every environment needs some shared memory semantics. In Erlang that's done with ETS tables, which don't undergo GC at all. Java's GCs are so good now, that, if shared data structures are used sparingly, would still give you better performance than BEAM. Plus, you have commercial pauseless GCs, as well as hard realtime JVMs. > Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library. edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades. The JVM is so versatile, though, that all this can actually be added as a lib

Well, the JDK's ArrayList, for example, will box ints into Integers, but there are primitive int lists that won't. With Go, AFAIK, the problem is exactly the same. Can you write, say, a heap or a read-black tree that can store wither ints and strings, that will embed the ints? Also, value types are making it into the JVM in Java 9. I don't think that will solve the packed representation in a generic data structure problem, but neither does Go. OTOH, Java does optimizations that Go never can. For example, Java can inline interface calls, which Go can't (and due to the way Go defines interfaces, method calls are slower than Java even when not inlined in either). Having said that, there are things about Go that I like better than Java: 1) no implicit primitive promotions (widening conversions), 2) a small standalone executable, 3) excellent

Actually, the closest we've got is Quasar[1] (I'm the main author). It's got true lightweight threads (goroutines), as well as selectable channels. On top, it's got actors, complete with selective receives and hot code-swapping. It is much more actively maintained than Kilim, more general, and has better performance to boot. Also, Quasar fibers interoperate very nicely with plain threads. Blocking operations (such as channel receive) block the thread if you're running in a plain thread, and the fiber if you're running in a fiber. In fact, we've even had time-sliced preemptive scheduling, which we've taken out because it didn't give performance benefits to fibers that block a lot, and for computations that don't, there's full blown threads (which Go doesn't have). [1]: https://github.com/puniverse/quasar

Don't forget Quasar: https://github.com/puniverse/quasar

When we implemented the Go and Erlang lightweight-thread approach for the JVM in Quasar[1], we quickly realized that CSP/actors, while going a long way towards sane concurrency, are not sufficient. Every application eventually needs some shared mutable state (even if it's implemented at the database layer). One approach is to have a single fiber (or goroutine) in charge of managing state (Clojure does that with agents), but that doesn't scale for multiple writers. Neither does a global lock over the entire data store. Good concurrent data structures that allow multiple concurrent writers are necessary. Java has some good basic ones like ConcurrentHashMap, ConcurrentSkipListMap, and ConcurrentLinkedQueue. Clojure takes that a step further with transactional refs. For more interesting kinds of data it's better to have a good in-memory trans

> At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking. It does. But it doesn't have to expose that as callback chains or promises to the whole over-arching infrastructure that sits on top. Concurrency units should be isolated from each other and internally execute whatever their logic is without having to worry about being polluted with callbacks. Then there could be multiple of such concurrency units executing in parallel but that is a the job of a decent VM/runtime/library to handle. > And at these levels of concurrency, you can’t go creating threads for every connection. Even something as simple as python gevent can create tens of thousands of green threads without a problem without exposing callback chains for everyone to see. Erlang VM and something like https://github.com/p

Java doesn't have a "concurrency engine", but a very large set of concurrency primitives: schedulers, locking and lock-free data structures, atomics etc. To answer your question, yes: my own library, Quasar[1], provides lightweight threads for Java. [1]: https://github.com/puniverse/quasar