There are various documents describing threading on Solaris/Linux, but nowwhere describing the Windows implementation. I have a passing interest in this, it seems strange that something so critical is (seemingly) not documented.
Threading is not the same on different OS' - "Write Once, Run Anywhere" isn't true for threading.
The document in question discusses the Solaris threading model and how the VM maps to it. This has nothing to do with Linux. Also, the document discusses performance only. The program's overall behaviour should not change no matter what you choose.
Java's exposed threading model is the same on every platform and defined in the Java specifications. To a Java application, the underlying OS should be completely transparent even for threading.
If you have to know, though ... The Sun JVM maps its threads 1:1 to Windows threads. It doesn't use multiple processes or fibers.
That document is a little more about Solaris threading than the Java threading model. All JVMs call the native thread API of the OS they're written for so there is always one Java thread for an OS thread. The diagram in the document shows that it's not until the threads are in the OS space that they change. Each OS can handle threads in different ways for Windows specific documentation here is a good place to start: MSDN About Processes and Threads.
For a long time various flavours of *nix have implemented their threads with processes rather than actual threads it seems that those specific tuning parameters where there to sort of ease the transition to a newer threading model in Solaris. Which made the older model and those JVM options obsolete.
For a list of JVM options for the HotSpot JVM you can look at: HotSpot VM Options. A lot of these are useful for tuning long running applications but you can also get into trouble with them if you don't understand what they're doing. Also keep in mind that each implementation of the JVM can have a different set of options you won't find some of them on IBM's VM or BEA's.
It really depends on the specific JVM implementation. I assume you're wondering about Sun's Windows JVM, and I can tell you with certainty that the Sun JVM maps a Java thread to an OS thread.
You could try spawning up a couple of threads from Java code, open up Task Manager and see what happened.
To answer you question most directly, precise semantics on how threads are implemented are deliberately left undefined by the JVM specification.
FWIW, Sebastion's statement that "Java's exposed threading model is the same on every platform and defined in the Java specifications. To a Java application, the underlying OS should be completely transparent even for threading", is inaccurate.
I have found significant empirical differences between threading under Windows and Linux regarding thread starvation using wait/notify. Linux is significantly more prone to starvation when the many threads contend for a single lock - to the extent that I had to load up 3 orders of magnitude more threads in Windows to cause starvation than in Linux. For heavily contended locks the Java concurrency locks with a fair modifier become critical.
To illustrate numbers, I had problems under Linux with one lock heavily contended by 31 threads, where the same code under Windows required 10,000 (yes, that's 10 thousand) threads to begin to demonstrate starvation problems.
To make matters worse, there have been 3 different threading models under Linux, each of which have different characteristics.
Mostly, threading has been transparent in my experience, but issues of contention deserve careful consideration.