Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Jakob Praher <jpraher@yahoo.de>
Subject: Re: Harmonizing on modularity
Date: Sun, 22 May 2005 18:03:35 +0200
Lines: 136
Message-ID: <d6qadj$v8f$1@sea.gmane.org>
References: <42909F67.8040503@cs.oswego.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
In-Reply-To: <42909F67.8040503@cs.oswego.edu>
Sender: news <news@sea.gmane.org>

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