Hi Doug,
thanks for joining the discussion.
Doug Lea wrote:
No matter whether you think you are starting with a JVM written in
Java or a micro-kernel-ish one in C (which seem to be the leading
options), you will probably discover that you end up writing most of
it in Java.
I think that a SystemJava dialect, like in Jikes (where the compiler
does the magic) is very interesting. I was and am a big Self/Smalltalk
fan, where this debate is much larger, but I also think writing the core
in a C/C++ can give some interesting points too. Some kind of language
argnosticism and the ability to export some features more easily to non
java systems, and I think when it comes to Address manipulation, C is
much more handy. [this is just my opinion]
As I said the most interesting part is that of a lower level common
infrastructure
a) to extend the vm more safely
b) to build bridges to other runtimes (parley)
c) to make pluggable extensions.
Implementing a middle layer in Java makes much sense to me.
For just about every major subsystem, you will find that
some of it has to be in Java anyway,
I would agree with you, but I wouldn't call it Java here. Because that
is mostly a very restricted sub-dialect of Java. ("No" invocation costs
of methods, etc).
and most of it turns out to be
better to write in Java. Steve Blackburn mentioned some of the
technical issues with respect to GC. Similar ones arise with
concurrency support, reflection, IO, verification, code generation,
and so on, as has been discovered by people developing both
research and commercial JVMs.
What your results from the OVM project?
Probably true. But I would favor:
* System langauge for the very low level infrastructure and to do
express raw access (pointers, explicit memory layout) to objects for
high performance very rare use.
* Special Java (JikesRVM like) to have a low level interface, which
abstracts from much very low level stuff (implemented on top/in terms of
that)
-> GC details
Perhaps even restrict much of Java's dynamic behavior for that.
Having multiple linkages would be interesting for that (implemented via
attributes for instance).
* Java for much of the rest
AFAIK working with LLVM is also a joy (it is written in C++) and this
has many advantages too.
One of the challenges here is that the Java programming language
curently does not make it possible to distinguish those classes
sitting in the JRE library (usually, the stuff in "rt.jar") that are
logically part of the JVM vs the normal APIs that normal Java
programmers are supposed to use. (Although most existing JVMs
dynamically enforce inaccessiblity of some APIs by exploiting rules
about bootclasspaths in some special cases, but this is not a general
solution.)
Good point. I would see it abit otherwise. One has to question what
classes are "system" on whose not. rt.jar is kind of grown out of suns
implementation. I think they have chosen this big rt.jar because you can
mmap it and you have access to all the "core" Java apis faster. I thinkk
one should make a distinction between classes which are closer to the vm
(for instance AtomcXxx would be of that kind) and others not
(xerces,xalan classes). rt.jar is much too coarse grained for that.
But making system classes cross vm implies that there exists some
special API for that, which is probably hard to achieve (as you said
below). But having such system classes would at least make explict
treatment of special classes much more easy.
I think this discussion soon gets into a java language/system debate,
because one could argue why we need to do this tight bundling between
the bunch of classes in rt.jar and the vm version. For instance: Why do
I have to wait for JVM 6 to fix that bug in Swing, which I need now in
my implementation. On the other hand this "expected behavior" is what
makes Java very appealing to integrators. ....
Independently, there has been a lot of discussion lately of possible
language enhancements resulting in some kind of module support for
J2SE 7.0 (Yes, the one after Mustang) to provide a more general
solution to the need for semi-private interfaces among subsystem-level
components, as well as for similar issues that arise in layered
middleware, as well as higher-level escape-from-jar-hell issues.
A powerful friend like approach would be very cool. I would like to join
the discussion on that.
Some
people would like to see a first class module system (see for example
MJ http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html,
as well as similar work at Utah http://www.cs.utah.edu/flux/) Some
people would like something more like a saner version of C++
"friends". I don't think that any of these have been subjected to
enough thought and empirical experience to make a decision about which
way to go.
:-) - I have started a modjava project at sf.net (modjava.sf.net) some
time ago, but doing it without the power of the vm sort of was not that
interesting to me. (Security issues, and not beeing able to faster then
jar based approach was some kind of frustrating) Also I haven't found
that momentum in the open source communities.
So it seems to me that this would be a good opportunity to harmonize:
Help work on possible forms of language-based module support, work
within JCP and with other JVM providers to eventually propel this into
the standard, and help shape the basic structure of a second/third
generation JVM.
Good advice. Looking forward for a JSR on that.
(Digression: The issues underlying all of this have long been a big
concern to me, but I spent a long time fruitlessly dealing with them
the wrong way. JVM providers don't want to standardize on the contents
of the APIs for intrinsics etc. But they should be pleased to
standardize on the way in which they are expressed.)
Having a standardized middle-layer IR, whith a well defined low level
type system and export format to store and transform the ir would be a
big step forward for me. Every advanced adaptible vm compiler does a
transformation of java bytecodes to at least a MIR before generating
processor code. If the format were standardized (like some kind of LLVM)
this would be *very* interesting. Also they have the ability to
implement instriscs via shared objects to extend the IR without
introducing new opcodes.
-- Jakob
