Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: harmony-dev@incubator.apache.org
Date: Tue, 24 May 2005 16:05:19 -0000
Message-ID: <20050524160519.30988.22230@ajax.apache.org>
Subject: [Harmony Wiki] Update of "JVM Implementation Ideas" by RodrigoKumpera

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 RodrigoKumpera:
http://wiki.apache.org/harmony/JVM_Implementation_Ideas

------------------------------------------------------------------------------
  
   * Idea: let objects' primitive fields grow upward from the object head and let reference fields grow downward from the object head. Object pointers pointing to objects themselves containing object references therefore point into the middle of the object's memory area.
   * Advantages: all object references are contiguous, which makes following these references during garbage collection, etc. easier and simpler.
-  * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC.
+  * Disadvantages: object head (lockword, vtable pointer, etc) is not necessarily at the beginning of an object's memory area, which can mean extra work to find the head when iterating through the heap e.g. during mark/sweep GC. Etiene notes that there is a performance degradation, mainly due to poor locality of this layout.
   * Origin: SableVM
  
  === Spinless thin-locks ===
@@ -37, +37 @@

  
   * Idea: threads must periodically check whether they need to do something. Typically this is done at backward branches. To make this check efficient, have the thread read a byte from a well-known page of mmap()'d memory. When another thread wants the thread to check-in, it simply maps that page unreadable. The target thread gets a signal, it does whatever check required, the page is re-mapped readable, and the target thread returns from the signal and continues on its merry way.
   * Advantages: efficient way to enforce checking in
-  * Disadvantages: requires mmap() and signals
+  * Disadvantages: requires mmap() and signals, signal latency can be an issue if the notification delay is critical, eg gc safepoints (see the paper from some Sun guys about this)
   * Origin: unknown/multiple; implemented in lots of places.
  
+ 
+ === Inline threaded interpreter ===
+ 
+  * Idea: similar to a direct threaded interpreter, but in the preparation step copy the code segment of some opcodes instead of pointer + data.
+  * Adavantages: faster interpreter.
+  * Disavantages: deciding with code segments can be inlined is a non-trivial, non-portable issue. A conservative aproach will result in worse performance.
+  * Origin: SableVM
+