RVM

Switch from pthread hijacking back to portable native sync for gtk AWT threading

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.9.1
  • Fix Version/s: 2.9.2
  • Component/s: Infrastructure: Test
  • Labels:
    None
  • Number of attachments :
    0

Description

Patch 12651 (reverted by patch 12666) reintroduced portable native sync for the gtk peer AWT threading. It removed a syswrap hijack of 2 pthread calls which prevented deadlock in GTk code. This introduced an inefficiency in the way scheduled AWT threads, but this was better than a deadlock. We should re-apply 12651 but we can only do this if Classpath is rebuilt on the test infastructure machines with --enable-portable-native-sync on their configure scripts. More generally the test infrastructure machines should rebuild Classpath.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

With Daniel's Classpath patch mechanism we should be able to enable portable native sync quite easily. We should schedule this for 2.9.2 as the pthread hijack fix is quite ugly and non-portable.

Show
Ian Rogers added a comment - With Daniel's Classpath patch mechanism we should be able to enable portable native sync quite easily. We should schedule this for 2.9.2 as the pthread hijack fix is quite ugly and non-portable.
Hide
Permalink
Ian Rogers added a comment -

Having reapplied the patch I'm witnessing the problem of the portable native sync code not being able to shut itself down properly. The VM gets stuck in a loop (see line 746 of the IA32 JNI compiler) where its expecting the VM_Processor to declare itself to be IN_NATIVE, if not it calls pthread yield. The comments say this should be because the VM_Processor is BLOCKED_IN_NATIVE, but for some reason the VM_Processor is actually IN_JAVA. As the transition of BLOCKED_IN_NATIVE to IN_NATIVE can never happen (we'd actually need a transition of IN_JAVA to IN_NATIVE) portable native syncing is currently causing the VM to deadlock.

Suggestions welcome, one idea is to change the spin loop in the JNI compiler to test for BLOCK_IN_NATIVE rather than IN_NATIVE and invert the condition of the test. It would be nice to catch whatever cause the native thread to have its VM_Processor status set as IN_JAVA.

Show
Ian Rogers added a comment - Having reapplied the patch I'm witnessing the problem of the portable native sync code not being able to shut itself down properly. The VM gets stuck in a loop (see line 746 of the IA32 JNI compiler) where its expecting the VM_Processor to declare itself to be IN_NATIVE, if not it calls pthread yield. The comments say this should be because the VM_Processor is BLOCKED_IN_NATIVE, but for some reason the VM_Processor is actually IN_JAVA. As the transition of BLOCKED_IN_NATIVE to IN_NATIVE can never happen (we'd actually need a transition of IN_JAVA to IN_NATIVE) portable native syncing is currently causing the VM to deadlock. Suggestions welcome, one idea is to change the spin loop in the JNI compiler to test for BLOCK_IN_NATIVE rather than IN_NATIVE and invert the condition of the test. It would be nice to catch whatever cause the native thread to have its VM_Processor status set as IN_JAVA.
Hide
Permalink
Ian Rogers added a comment -

So the failure is that gtk peers uses an atexit routine. When we call the system call exit this is triggering the atexit routine that is calling JNI methods that can never enter as the system call doesn't transition the virtual processor status from IN_JAVA to IN_NATIVE. There are several fixes but I think the most obvious is to remove the sysExit system call and change it into JNI code. Does anyone disagree?

Show
Ian Rogers added a comment - So the failure is that gtk peers uses an atexit routine. When we call the system call exit this is triggering the atexit routine that is calling JNI methods that can never enter as the system call doesn't transition the virtual processor status from IN_JAVA to IN_NATIVE. There are several fixes but I think the most obvious is to remove the sysExit system call and change it into JNI code. Does anyone disagree?
Hide
Permalink
Ian Rogers added a comment -

r13697 closed/fixed this.

Show
Ian Rogers added a comment - r13697 closed/fixed this.

People

  • Assignee:
    Ian Rogers
    Reporter:
    Ian Rogers
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: