Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: This week on harmony-dev (Sept. 04 - Sept. 10 2005)
From: David Tanzer <struppi@guglhupf.net>
To: "harmony-dev@incubator.apache.org" <harmony-dev@incubator.apache.org>
Content-Type: text/plain
Date: Sat, 10 Sep 2005 21:16:35 +0200
Message-Id: <1126379795.2492.5.camel@Elrond.Rivendell>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Mladen Turk responded to the concerns by Weldon Washburn about the
"light-weight native calls" in the thread "VM/Classlibrary Interface 
(take 2)". He explained in more detail how he thinks those light-weight
calls could work, they should avoid the overhead for native calls.
Mladen and Tim Ellison then discussed what this means for the native
methods which are called (for example, they would not be allowed to
allocate objects on the heap). Such light-weight native calls could
pontentially speed up the class library since often native calls don't
need to create any objects (or use other operations which would be
disallowd by the light-weight model).
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c4319C1E4.5000405@apache.org%3e]

Also in the "[arch] VM/Classlibrary Interface (take 2)" - thread, Tim
Ellison explained how the interface between their class libraries and a
JVM works. These class libraries are a subset of SE and have been
independently developed. They are designed to be portable across VM
implementations but have been principally written against the J9 VM.
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c431C17A9.7080200@gmail.com%3e]

Tim Ellison posted in the thread "[arch] VM/Classlibrary Interface ( VM
Accessors )" that VM Accessors would be some kind of "classlibrary 
developer's toolkit" and could allow implementation of functionality in
pure Java which would otherwise require a native implementation. He also
mentions that the list of accessors Rana Dasgupta wrote is a blend of
functional enhancements and optimization enhancements. The security
concerns for these accessors could be solved by the componentization of
the class library.
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c431C2061.7080008@gmail.com%3e]

Sombody at roomity.com announced that GNU Classpath 0.18 has been
released. In the discussion in this thread, Mark Wielaard told us that
since the start of harmony the number of contributions a day to GNU
Classpath have tripled and and a little bit more about the release. He
also mentioned that the classpath/harmony sister projects will release
an updated version soon. Robert Lougher posted that "JamVM from CVS
works with classpath 0.18 'out of the box' on Linux now". There was also
some discussion about porting Kaffe to PSP and XBox 360, but I guess
this will be continued in the Kaffe project. Dalibor Topic, Tom Tromey
and I where involved in this discussion too.
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c72053.81126091004727.JavaMail.tomcat5@slave1.roomity.com%3e]

Xiao-Feng Li started a thread called "[Arch] Class unloading and VM
objects reclaim", where he discribes 2 approaches how to unload a class.
One approach would encode VM objects similar to app objects, so they can
be reclaimed by the GC, the other treats class unloading specially and
reclaims the memory with the class loader. Archie Cobbs said that you
can have the benefits of both approaches by having a per-class loader
memory area, but Xiao-Feng wrote that this looks like the second one he
suggested. There was also some discussion about situations where objects
(especially strings) could not be relclaimed with these approaches and
how to solve this, Peter Edworthy and Santiago Gala posted some
interesting facts on this topic too.
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c9623c9a5050907194513922548@mail.gmail.com%3e]

In the thread "[arch] voluntary vs. preemptive suspension of Java
threads" Xiao-Feng Li posted that they had some difficulties in
maintenance and portability with code patching (i.e. the VM patching
compiled code at save points to stop a thread). He suggests we implement
both approaches (preemtive and voluntary, voluntary first) for further
study since the two approaches are not much conflicting.
[http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c9623c9a505090916191116401@mail.gmail.com%3e]

Regards, David.

-- Read the archive of this series at http://deltalabs.at/
-- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed
-- Also aggregated at: http://planet.classpath.org/

-- 
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
AUFGABEN DER PHYSIK -- QUANTENMECHANIK
Gegebene Konstante: m(Kuh)=400 kg

Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der
Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann.
Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb
der Weide antrifft.