[Jikesrvm-core] [ jikesrvm-Patches-1444139 ] Fixes to allow AWT to work (more to be done)

[SourceForge.net <no...@so...>]

Patches item #1444139, was opened at 2006-03-06 13:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712770&aid=1444139&group_id=128805

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Rogers (captain5050)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixes to allow AWT to work (more to be done)

Initial Comment:
This patch is an initial attempt to address bug
1147592. More information is now known about this bug
and I propose closing it and starting new more specific
bugs to address the problems raised. The attached patch
is a proof of concept to show that classpath's AWT gtk
peer code can run in the modes that will be described
in the new bugs.

About the patch:

the patch is a tar ball comprising the file
jikesrvm_awt_patch which is the main part of the patch
against the Jikes RVM. The particular problem the patch
is trying to address is that because we can transition
from Java to Native to Java, we can yield between two
Java threads on the same pthread/VM_VirtualProcessor
and end up on the same pthread in 2 pieces of native
code. The 2nd thread we enter can't reschedule the 1st
thread unless the 2nd thread enters Java code. If the
2nd thread is waiting for a lock held by the 1st thread
then we deadlock. The patch addresses this problem by
trying to stop the 1st thread from (green thread)
yielding until it has left the native code.

The patch also contains some differences to classpath
and to VM_Wait. This is in an effort to reduce
contention on VM_Processors to be the native thread.
The classpath patch in particular stops the gtkMain
thread from becoming blocked in native code, as this
easily exhausts the pool of daemon processors and
initially causing GC barriers to fail.

The state of AWT following the patch:

Testing of AWT has been performed using the
ScribbleFrame application from the Java in a nutshell
book. This application will run on a prototype build,
albeit slowly. To prevent VM_Processors from being
contended by too many threads it is necessary to
specify the -X:processors= option to the Jikes RVM.
Unfortunately the patch won't prevent deadlock
occurring, so its not fair to say this patch fixes the
AWT for the Jikes RVM.

License:

        STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, _Ian Rogers_: 

(a) represent that either:

  (i) I am the only author and owner of the contributed
software 
      (described as/entitled _AWT fixes for Jikes RVM_), 
      which was neither derived nor copied from any
other software,
  or 

 (ii) that any exception to (i) is software which was
obtained under the 
      CPL (Common Public License), 

and   

(b)  hereby agree to license this contributed software
under the CPL.

New bugs:

(1) "Portable native sync code" a gthread to Java
wrapper is broken (and is also broken by concept). A
gthreaded application can create the Jikes RVM,
switching the threading primitives upon entry to gtk
peers. This will break the gtk application and prevent
the Jikes RVM from being used as a plugin.

(2) Multiple native threads can contest the same lock
on the same pthread resulting in deadlock.

(3) It is only possible to move one blocked in native
thread onto the daemon processor. A solution may be to
allow an extensible pool of daemon threads with native
code being transferred to one before they can acquire
locks, etc.

Thanks,

Ian Rogers

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712770&aid=1444139&group_id=128805