Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

Fwiw, the original implementation of threads in Java were 'green' threads (it was project Green after all). These were implemented in SunOS (vs System V) using setjmp/longjmp and an some auto-yield logic in the JVM (basically when you did certain things it would start that thing and yield your thread while it completed). When I started I had the most System V experience so I ported it over the Solaris to get to what was affectionately called the 'hello hello hello world world world' stage. The choice to use the Solaris native threads over green threads was motivated by the work that had gone on in the Solaris kernel to do CPU scheduling efficiently. That gave Java multiprocessing for 'free'. Except it exposed a bunch of bugs in the mutex / synchronized code when you actually got parallel execution :-).

The magic, as the author points out, is dynamic stack allocation. If you disassociate a thread with a required stack size, then you are back to using just the amount of memory that your object heap and reference stores are using. GC gets to be trickier to of course.

This should nominally be a non-issue on 64 bit address machines as you only need map the pages that actually have data in them (minimum one page) but that still puts a huge load on the page tables. This is especially true with huge pages which are used to avoid tlb thrashing and to save on the number of levels you have to go through to get back the physical address of the page you are trying to access.

Its the kind of optimization problem that systems folks really like to dig into and optimize around.

You could do 1:1 threads with dynamic stack allocation too. SML/NJ heap allocates all stack frames in userland, for example.

> allocates all stack frames in userland

Where else can you allocate stack frames except for in userland?

Nowhere else, and that's my point. :)

It was my general impression that porting Java found native threading bugs in multiple OSes. How stable or portable were native threads before that?

This was 1992 and Posix, BSD, Microsoft, and a contingent from HP/Apollo were all putting forward ideas about what the API to 'threads' should be and even whether they were a "kernel" thing or a "user level" thing. Arguments were made that lightweight processes were the abstraction to use but as I recall that impacted portability.

So yeah, they were pretty new and they were blowing up things left and right. Sun at the time had a leg up on most (if not all) UNIX vendors with a threading model that worked well. But it made porting the JVM harder and green threads lived for a long time as a fallback.

How user level lightweight threads were supposed to utilize multiple processors?

assuming the question implies "without using threading" - spawn multiple processes and migrate fibers across them as needed.

of course it's not something a developer might want to do, but might be done as part of an user-land library. no idea why one would want that today outside of highly specialized code, but it might be that it could be more portable to other kind of non-preemtible system (i.e. os with fixed time sharing)

> The magic, as the author points out, is dynamic stack allocation. If you disassociate a thread with a required stack size, then you are back to using just the amount of memory that your object heap and reference stores are using. GC gets to be trickier to of course.

I would imagine register based VMs have a leg up in this regard?

> I would imagine register based VMs have a leg up in this regard?

That doesn't make any sense - register VMs have exactly the same requirement for stack frames as stack based VMs do.

As I understand it, stack-based VMs use a stack for the operands that the VM instructions operate on, whereas a register-based VM puts the operands in registers rather than a stack. Both types of VMs use a stack for the function call stack (which is not the same stack as the operand stack), though, so there is no difference in that regard.

Is it possible today to have a compliant Java implementation using green threads? Seems like something that would appear in Azul first.

Neither the JVM nor the Java specifications impose restrictions on this, so theoretically I'd say it's possible.

There is a proposal to add fibers to Java: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...

Project Loom [1] is intended to provide green threads, or 'fibers', at the JVM level.

There have been other projects like Quasar from ParallelUniverse [2] that retrofits them by processing the compiled bytecode to enable saving/restoring the IP & stack.

[1] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...

[2] http://docs.paralleluniverse.co/quasar/

Kilim [1] (afaik) was first in this space. (edit: just FYI)

[1]: http://www.malhar.net/sriram/kilim/kilim_ecoop08.pdf

Reply on news.ycombinator.com