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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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". [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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.". [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] 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.
