I agree with Charlie about microthreads being baked in to the VM and the JDK.
I explored the possibility (for Kilim) of making Thread m:n again, but switching stacks and growing them dynamically is a pain in Hotspot. The Capriccio project from Berkeley grows the stack at run-time, but depends on a static analysis to figure out where to put the check to grow the stack dynamically. I am now beginning to explore a more interesting alternative (seen in Kilim), where the user-level thread and the kernel thread schemes have a loose coupling that is exposed to the programmer. This permits finer grained control over the mapping of m to n and how the tasks are scheduled. Maintaining cache affinity is important for some applications and you don't want to make a thread jump around. So, in Kilim, a Scheduler manages a thread pool, and you can have many independent schedulers. A task belongs to a scheduler at any point in time. (By default, there's one scheduler and one thread pool) You can of course write your own scheduler. This is good for writing simulators (JIST-style) that can schedule tasks according to a logical clock. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
