Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Apache Wiki <wikidiffs@apache.org>
To: commits@harmony.apache.org
Date: Fri, 15 Feb 2008 19:12:53 -0000
Message-ID: <20080215191253.7802.10940@eos.apache.org>
Subject: [Harmony Wiki] Update of "DRLVM Development Tasks" by Vladimir
 Beliaev

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Harmony Wiki" for change notification.

The following page has been changed by Vladimir Beliaev:
http://wiki.apache.org/harmony/DRLVM_Development_Tasks

------------------------------------------------------------------------------
  
  '''''Task:''''' Reimplement main thread processing in launcher.
  
+ == Application Binary Interface Glue ==
+ 
+ === 6. Unify JIT/VM ABI glue (replace 5 approaches with a single approach) ===
+ '''''Problem:''''' Currently there are five approaches to generating ASM that translates from JIT ABI to C/C++ ABI. This glue also deals with exception throwing and live reference enumeration. The five approaches are: 
+  * Microsoft ASM 
+  * Linux/gcc ASM 
+  * JIT back-end (hardcoding what gets emitted by using the JIT emitter) 
+  * LIL 
+  * vmmagic (currently allows type-unsafe memory read/writes from Java) 
+ 
+ The above five approaches times two architectures (x86 and x86_64) means we have 10 distinct, hard to maintain kinds of asm in the code base. The goal is to reduce this to the bare minimum – one for x86 and one for x86_64. First, determine if we can use a combination of vmmagic and JIT intrinsics to accomplish the task. Second, if the above is doable, cleanup the old ASM code.
+ 
+ '''''Task:''''' Replace 5 approaches to JIT/VM ABI glue with a single approach.
+ 
+ == Finalization System ==
+ 
+ === 7. Improve Finalization Work Balance Mechanism (FWBM) ===
+ '''''Problem:''''' FWBM was changed with a move to new Garbage Collector (GCv5). This resulted in FWBM becomes not well adjusted, the finalization system behaviour differes from RI one which may be critical for stability and performance of resource critical applications. One needs to evaluate FWBM in DRLVM and RI, identify issues (e.g. one may relate to dead lock between finalizer thread and another thread using same monitor) and get them resolved.
+ 
+ '''''Task:''''' Evaluate compatibility with RI and make required improvements.
+ 
+ == Monitor support ==
+ 
+ === 8. Release monitor in unwinded frame ===
+ '''''Problem:''''' There are three cases when monitor must be released:
+ 
+  * when exception handling
+  * when the owning monitor thread dies in unusual place (say due to `exit` call)
+  * when JVMTI `PopFrame` is called
+ 
+ The support for all three cases should be implemented. Also support for first two cases is performance critical (must be implemented in optimal way).
+ 
+ '''''Task:''''' Implement monitor releasing for frame unwinding.
+ 
  === <name> ===
  '''''Problem:''''' .
  
  '''''Task:'''''
+ 
  
  == The task fromn old list which required clarification ==