Re: [arch] Modular JVM component diagram

[Weldon Washburn]

On 9/23/05, Robin Garner [EMAIL PROTECTED] wrote:
 Weldon Washburn wrote:

  Everyone,
  I just posted the basics of the GC/VM interface to
  http://wiki.apache.org/harmony/HarmonyArchitecture.  The VM calls into
  the GC using gc_interface.txt.  The GC calls into the VM using
  vm_gc_interface.txt.
Weldon
 
 
 Thanks Weldon, it makes very interesting reading.  I've posted a
 description of MMTk's VM interface on my web page,
 http://cs.anu.edu.au/people/Robin.Garner/, for comparison.  This is the
 GC - VM interface.

Great!  Its good you are documenting MMTk interface.  I will take a
look at it soon.  Please think of the interfaces that I posted as a
starting point.  Also, don't feel shy about ripping apart the
interfaces I have posted.  The whole point is to quickly evolve
Harmony into something more sophisticated than the existing JVMs.


 As described in my thesis (although if you want to read it, remember it
 is now nearly 2 years out of date, and MMTk has moved on - link is also
 on my ANU web page), we follow a wedge model of the interface, rather
 than specifying a simple flat API.  So while JikesRVM (and Rotor and
 JNode) have a definite API that they code to, there is a package that
 translates this to fit the services MMTk offers.  And that's a large
 set, not yet documented (beyond source and javadoc in any case).

 I'm going to look more closely at the interface you've posted, and will
 probably have more questions in a short while, but my first
 impressions/questions are:
 - The interface seems tightly coupled to ORP and Sapphire.

Sapphire has been backed out of the source base.  As far as I know,
the GC interface I posted has not been used any place but ORP and its
follow-ons.

  For example,
 since there aren't any API calls to do it, I presume the GC knows how
 the object header is laid out ?  And knows about something called a
 vtable ?
True and true.

 - It's not explicitly specified in the API, but I assume gc_alloc_fast
 is inlined (or is a macro) ?
gc_alloc_fast is intended to be inlined.

 - Doesn't supporting gc_pin_object restrict the GC implementation
 significantly ?
This might have been one of the APIs left over from when we extended
ORP to run ECMA CLI (.net).  I might have forgotten to remove it.

 - I was under the impression ORP doesn't yet support weak references or
 finalizers.
Stay tuned for more info.

 There appears to be support for the GC to tell the VM about
 reference types, but not the other way round.  Is this right ?  Or is
 this the gc_add_weak_root_set_entry call ?
 - How does the VM enumerate the thread stacks ?  Is this the
 gc_add_root_set_entry call ?
I will have to take a look and get back to you.


 Do you have any documentation specifying what else the GC talks to ?
 I'm assuming that for its own synchronization, interfacing with the OS
 (mmap etc) it talks directly with the OS, glibc etc.

Yes.  I have been waiting to see what response I get to what's already
posted before posting more stuff.


 Cheers,
 Robin




--
Weldon Washburn
Intel Managed Runtime Division

This week on harmony-dev (Sept. 18 - Sept. 24 2005)

[David Tanzer]

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