So the "original" move to native threads was motivated by the fact that Sun didn't want Java to be SunOS only (there were a number of SunOSism's in it when it was Oak). That the system threading system would improve independently of the language and have fewer edge cases were put forth as good reasons to do that.

Initially it was slower because context switches are slower, and anything that had to context switch into and out of the kernel was thus slower. Later there were other reasons. "User level" or as I prefer "Single Context" [1] threads have the ability to be very fast because they have extra knowledge about what is going on and access to other address spaces (so you don't have to save something if you know how it's used). There has been lots of great work on this since the early 90's when this decision was made so I suspect the issue would be significantly less.

[1] At the time kernel threads were 'single context' and quite fast. Fast enough to be used for interrupts. There is a great paper on the threading system in Solaris which describes them. -- http://dl.acm.org/citation.cfm?id=202217

Naturally, we've experimented a lot measuring context-switch cost. While pretty bad on OS X, on Linux it's quite good in many circumstances (sleep, IO interrupt) but not so good when a thread waits to be woken up by another application thread (as opposed to being woken up by some kernel event). Aside from consuming less memory, Quasar fibers shine exactly in that last scenario: when fibers wait on other fibers (they could be waiting for an actor or channel message, a condition variable, or an in-memory DB transaction). Fibers use Doug Lea's awesome fork/join thread pool for scheduling.

I hope to write about our context-switch results some day.