Similarities to thin threads from JRockit?

[Florian Weimer]

* Magnus Ihse Bursie:

> However, in the real world, most applications did not behave like
> this. Interaction with native code (most likely not as common today as
> when JRockit started) was a big problem, maybe the biggest. Scheduling
> was a hard issue -- not unsolvable, but seriously technically hard. We
> used what we called "MxN", mapping M thin threads on N native
> threads. Then you had to fight with the CPU on the scheduling of the N
> native threads on the P number of CPUs. Also, when a worker thread got
> caught in JNI too long, we spawned a new native thread to continue
> execute from the thin thread pool. This made the hard scheduling
> problem re-occur every so often.

I would also caution that, once JNI is involved, resuming a thin thread
on a different native thread is more problematic than it used to be, due
to an increased use of thread-local storage in native code.

These days, it could be necessary to only ever resume a thin thread on
the same native thread once there was a JNI call on that thread.

Thanks,
Florian