harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tanzer <stru...@guglhupf.net>
Subject This week on harmony-dev (Sept. 18 - Sept. 24 2005)
Date Sat, 24 Sep 2005 19:26:43 GMT
Well, it was an interesting week with a lot of discussions, so
this week's summary is a little bit longer than the weeks before.

At the beginning of this week I posted some more infos about my
proof-of-concept component model implementation, which started some
interesting discussions. One was about the component model itself in
the thread "[arch] VMCore / Component Model", where various posters
pointed out that we must not take performance issues lightly. It has
also been discussed how this would affect code inlining and the JIT.
Robin Garner gave us some good arguments why he thinks we should aim
for compile-time (and not runtime) configurabiltiy for the components.
Other people involved in this discussion where: Peter Edworthy and 
Geir Magnusson Jr.

Geir Magnusson Jr. has forked the discussion about component models
to "Code into SVN, not the WIKI  (Re: [arch] VMCore / Component Model)",
where we discussed some general points in the contribution policy of
harmony. Andy Oliver and Davanum Srinivas joined this discussion, which 
was then about how hard or easy it should be to become a committer in 
this project.

Andy Oliver started a thread called "4 Months and..." which was then
renamed to "Call for Contributions (was Re: 4 Months and...)", and this
thread was about opening the repositories so people can easily submit 
code. Geir Magnusson Jr. again posted a call for contributions, and then
he and Andy Oliver discussed if this attracts people to commit. Later
this week, Rodrigo Kumpera contributed a JVM he has written in Java.

The discussions mentioned above lead to the thread "[discussion]
Committer Addition Process" where Geir Magnusson Jr. suggested a process
for adding committers. He and Andy then discussed if this process is too
formal or not and Andy posted an email "exploiting" some unclear parts 
of Geir's proposal. Leo Simons answered him that he can stop playing 
"devil's advocate" now, and that these legal concerns are important to
us because we're aiming to do a full and compliant J2SE effort.

Also in this thread, Davanum Srinivas posted that he was looking for
specific timelines and actions sombody can do to get commit status. Geir
answerd "Offer a patch or contribution.  That's pretty specific.". 
AFAICS the status now is that people who want to contribute something
they should do this as a JIRA contribution when they don't have commit
privileges yet. Geir explained this in detail in the email "How to
package a contribution". All things discussed here also made some
changes in the ACQ nessessary, Geir informed about them in "[legal]
Change to Authorized Contributor Questionnaire".

There was a long discussion if the harmony JVM should have an
interpreter and an optimizing JIT or if it should have no interpreter,
but instead a fast, non-optimizing JIT in "[arch] Interpreter vs. JIT 
for Harmony VM".

The arguments for having an interpreter too are:
* A traditional interpreter is easy to port.
* Writing a portable JIT seems more difficult.
* Implementing JVMTI will probabaly be easier.
* An interpreter/JIT environment might use less memory.
* Very compact interpreters (<100K) can be constructed for memory
  constrained environments.
* Flexibility: A well-written interpreter is easy to modify for research
  or experimental purposes and can trivially support runtime-pluggable 
  features like debug and instrumentation.

The arguments for the JIT-only version are:
* A fast code-generating JIT can call runtime helpers and native
  methods without additional glue code.
* Code reuse: The structures required to support a zero optimizing JIT 
  would also be used by optimizing JITs.
* "Having a mixed JITed-interpreted enviroment makes things harder".

(I hope I found all the arguments which have been posted). People
involved here where:
Steve Shih-wei Liao, Geir Magnusson Jr., Andy Oliver, Peter Edworthy, 
Tom Tromey, Will Pugh, Michael Haupt, Rodrigo Kumpera, Santiago Gala, 
Frederick C Druseikis, Robin Garner, Michael Hind and Graeme Johnson.

Later in the same discussion, Will Pugh explained some more details
about the effect of both approaches on our JVMTI implementation and 
he "grouped the JVMTI capabilities into groups of which I think are 
orthagonal to the issue, ones that would be significantly easier on an 
interpreter vs. compiled code, and then further into what I think would 
be more difficult in optimized code vs. non-optimized.".

Also in this thread, Michael Haupt asked if startup-time in a JIT-only
environment could be increased by caching the code on disk. Will Pugh 
and Tom Tromey explained that this is possible and what has to be
considered to make this possible.

In the thread "[Arch] Suggestion to prioritize JVMTI over JVMPI and
JVMDI", Chris Elford suggested we should "concentrate our debug/tools 
interface work in Harmony to making JVMTI work really well and let JVMPI
and JVMDI fall away". Geir Magnusson Jr. pointed out that we can only do
so if we jump ahead to J2SE 6 rather than implement J2SE 5 (assuming 
they are dropped), but as long as we are working on J2SE 5 we have to
support them.

Xiao-Feng Li wrote an email called "[arch] On finalizer design" where he
writes some points about finalizers in a JVM and he asks how others 
think about this. Robin Garner and Weldon Washburn discussed about the
VM/GC interface Weldon posted earlier in the thread "[arch] Modular JVM
component diagram". Robin posted a link to a paper where he discribes
the VM -> GC interface of MMTk and asked some questions about the
interfaces posted by Weldon, and Weldon answered them and said he'll
post more info later.

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
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.

View raw message