6 ms·
Aside from preemption, the other notable difference is process management. They are incredibly lightweight in terms of RAM and CPU usage. You can create million
by teilo 8y ago
Aside from preemption, the other notable difference is process management. They are incredibly lightweight in terms of RAM and CPU usage. You can create millions of them because they do not map directly to kernel threads, and thus to not incur the overhead associated with them.
On the contrary, the JVM uses kernel threads (except for old obsolete versions of some JVM implementations which supported green threads which ran in userspace), which are much more expensive. Because of this the JVM offloads thread scheduling to the OS. BEAM handles process scheduling internally.
- brightball 8y agoLightweight meaning 0.5kb for a BEAM process vs 1024kb for a JVM thread. A goroutine in Go is 2kb for comparison sake.
- masklinn 8y ago> lightweight meaning 0.5kb for a BEAM process It's quite a bit more than that. According to the offical doc[0] it's 309 words without SMP or HiPE, on my machine (with both) it's 336 words. That's 1.2~1.3k on a 32b system and 2.4~2.6 on a 64b system. [0] http://erlang.org/doc/efficiency_guide/processes.html http://erlang.org/doc/efficiency_guide/processes.html
- derefr 8y agoProduction Erlang systems tend to take advantage of hibernating many of their “millions of processes”, though, since it’s a rare architecture where those million processes are all hot. If you look at the memory usage of such systems, it’s a lot less than that figure would imply, mainly because of process hibernation.
- masklinn 8y agoThat is true, best-case scenario (a process storing no data whatsoever) hibernating can remove the 233 words minimal heap (and stack) preallocated, yielding 76 words without hipe or smp, or 103 with them, for 304 / 608 / 412 / 824 bytes (nothing/32, nothing/64, hipe+smp/32, hipe+smp/64).
- brightball 8y agoI came across that number a couple of years ago when I was doing research for a presentation. It may have been from a book but I'll see if I can dig up the source.
- masklinn 8y agoAs derefr notes, it might have been the size of a hibernating (rather than live) process. It's 0.3~0.4k on 32b systems, though 0.6~0.8 on 64b ones.
- kuwze 8y agoI have been out of Java programming for a while. Why/when were green threads deprecated?
- teilo 8y agoThey were considered a workaround for architectures that didn't have native multi-threading. I don't remember when they were dropped, but it was well before the Oracle acquisition.
- Someone 8y agoThe JVM ran all its green threads on a single CPU, even if multiple CPUs were present. When multi core systems became more common, Sun faced the choice of overhauling the green threads implementation or going to us system threads. I don’t know why they made the choice, but it likely was a combination of time pressure (writing and tuning a good m:n green threads implementation is hard) and doubts about the usefulness of green threads on multicore systems.
- pjmlp 8y agoExcept JVM is going to get fibers, co-routines and tail calls in a future release. "Project Loom with Ron Pressler and Alan Bateman" at this week's JVMLS 2018 https://www.youtube.com/watch?v=J31o0ZMQEnI https://www.youtube.com/watch?v=J31o0ZMQEnI
- geodel 8y agoInteresting. It seemed to be independent library before. May be shoving it inside JVM lead to more usage finally.