harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [drlvm][gcv5] finalizer design
Date Thu, 14 Dec 2006 19:17:55 GMT
Harmony-2560 adds a second finalizer implementation to the Apache code
base.  H2560 is a GCV5 patch.  Reading the new code and running regression
tests, it looks like a fairly simple extension of the existing code that
probably does not disrupt the original finalizer code.  I say "probably"
because H2560 passes the basic commit test ("build test").  But "build
test" does not exercise finalizers to any degree.

In any case, long term we need just one finalizer design and
implementation.  I would like to see a discussion on the merits of each of
the finalizer approaches.  It would be good to pick one approach within one
week.  Then we can clean up the code to reduce confusion.

For reference, the existing vm code that is impacted by H2560 is:

vm/vmcore/src/init/finalize.cpp
  -- adds logic to switch between the original finalizer code and gcv5
supplied code (4 locations)
vm/vmcore/src/init/vm_init.cpp
 -- adds calls to gcv5 specific initialization routines
kernel_classes/javasrc/java/lang/FinalizerThread.java
  -- adds logic to switch between the original finalizer code and gcv5
supplied code (3 locations)
   -- adds new native method definitions to support gcv5 finalizers
kernel_classes/native/java_lang_FinalizerThread.cpp
  -- add the implementations of the native methods defined in
FinalizerThread.java (above)

Note that mods such as new header file inclusions and totally new files were
not included since these have very low impact on the execution of the
existing finalizer algorithm.

-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message