Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.9.2
-
Component/s: Runtime: Threads and Concurrency
-
Labels:None
-
Environment:All
-
Number of attachments :
Description
We currently support a single M-of-N thread model, where M Java threads are mapped onto N underlying processors. N should never be greater than the number of processors in the system for GC barriers to work correctly, however, a thread that blocks in native decreases the value of N by 1. For this reason we keep a spare processor handy, but the system will block with 2 blocking threads (also shifting execution of C code from one VM_Processor to another is highly dodgy). There are probably many others reasons an M-of-N thread model isn't desirable, so we should endeavour to implement a more regular pthread thread model, where Java threads are mapped directly onto underlying operating system native threads.
The integration of a lot of the code is great, but also a problem when pulling things to pieces. For example, VM_Lock holds information on thick locks, however, it's data structures reside in the scheduler and it knows how to queue/dequeue green threads directly with the scheduler. As part of refactoring the thread model it makes sense to break some of these links (for example locks aren't dependent on a green or pthread scheduling mechanism) and make appropriate accessor methods for the underlying scheduling system. If this is green thread specific then my aim is to make this reside in org.jikesrvm.scheduler.greenthreads.