Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.9.2
    • Labels:
      None
    • Environment:
      All
    • Number of attachments :
      0

      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.

        Issue Links

          Activity

          Hide
          Ian Rogers added a comment -

          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.

          Show
          Ian Rogers added a comment - 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.
          Peter Donald made changes -
          Field Original Value New Value
          Component/s Runtime: Threads and Concurrency [ 12865 ]
          Peter Donald made changes -
          Link This issue is duplicated by RVM-91 [ RVM-91 ]
          Andrew John Hughes made changes -
          Link This issue is depended upon by RVM-135 [ RVM-135 ]
          Hide
          Ian Rogers added a comment -

          My hope is that I've cleaned up the JSR166 TCK failures and deadlocks this week, once this is sane or has known deficiencies we should move it to the head following IA32 and PPC full sanity tests. Work continues in the RVM-91 branch.

          Show
          Ian Rogers added a comment - My hope is that I've cleaned up the JSR166 TCK failures and deadlocks this week, once this is sane or has known deficiencies we should move it to the head following IA32 and PPC full sanity tests. Work continues in the RVM-91 branch.
          Hide
          Peter Donald added a comment -

          While you are knee deep in this code can you look into allowing a larger number of threads. Trunks seems to die at 135+ threads.

          Show
          Peter Donald added a comment - While you are knee deep in this code can you look into allowing a larger number of threads. Trunks seems to die at 135+ threads.
          Hide
          Ian Rogers added a comment -

          This is fixed in r13106. Peter, could you produce a test case for the many threads problem as I imagine it still persists (I refactored the code but didn't change any internal limits).

          Show
          Ian Rogers added a comment - This is fixed in r13106. Peter, could you produce a test case for the many threads problem as I imagine it still persists (I refactored the code but didn't change any internal limits).
          Ian Rogers made changes -
          Resolution Fixed [ 1 ]
          Fix Version/s 2.9.2 [ 13599 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 3.0 [ 13530 ]
          Ian Rogers made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Ian Rogers
              Reporter:
              Ian Rogers
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: