harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: Terminology etc
Date Tue, 24 May 2005 09:22:05 GMT

>if the spokes were in Java but the hub in C, would we then lose
>all of the aggressive inlining benefits that Java-in-Java solution can
>provide?

I guess that if we use an LLVM based solution this would not be an issue
anymore (for that matter, this might be true for .NET based solution too, as
there are C to .NET compilers [1])

I really like that "hub" story as there will be a relatively big run time
lib to import to get a usable system, which might need some interface that
is far better than JNI interfaces [3] (ex: graphics system - and high perf
computation support through GPU for amateurs, lol [2]). Without a unified
interface...

Rgds,

RB

[1] although the P/invoke question might turn into an infinite loop... lol
[2] not seriously for the beginning, of course, yet there are apps in
scientific computing where it is /really/ a big speed up, (including sparse
matrix solvers and so on) and of course it is true too for 3D apps. Anyway
enabling fancy optimizing for modern apps could boost the coolness factor.
[3] For instance, for graphics pipeline, it might be interesting to be able
to express graphical instructions in the "readable" order but at the same
time to have an opportunity to reschedule them automagically. Same with the
usage of SSE/MMX-like instruction sets (many optimizations indeed consisting
in using high-level properties of the objects we manipulate).

-----Original Message-----
From: Dmitry Serebrennikov [mailto:dmitrysj@earthlink.net]
Sent: Tuesday, May 24, 2005 5:49 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc

This is excellent! For one, I find Java-in-Java to be much clearer after
this little set of definitions.

A quick proposal: perhaps "VM bootstrap" as used below should really be
something like "VM initialization," "VM init," or even "VM startup",
since the word "bootstrap" is very specific and to me at least,
indicates something more akin to the "VM bootloader" + "VM boot image"
(as used below).

I'm going to try to make a couple of observations. Please forgive the
rambling :)  It just seems like things are starting to take shape...

* It looks like there is really not much in common between this
architecture and one where "VM core" would be in C... For that one, "VM
core" would be in C, as would be all of the components, such as GC,
scheduler, etc. "VM init" doesn't sound like a big deal but would
probably also be in C. "VM boot image" and the "VM bootloader" are
simply not present in a C solution.

* "OS interface" is perhaps one place where some code can be shared. If
C version can benefit from an OS abstraction layer for portability, then
it seems like this layer could be shared between the C and the Java
implementations.

* The meat of the VM seems to be in the "spokes" that connect to the "VM
core-hub". It seems that this is where it would make the most sense to
mix components written in C with those written in Java, to see which one
can do a better job. If all spokes were in C, it would make little sense
to have the hub be in Java... On the other hand if spokes are all Java,
it makes little sense to have the hub be in C.

Steve, if the spokes were in Java but the hub in C, would we then lose
all of the aggressive inlining benefits that Java-in-Java solution can
provide?


-dmitry

Steve Blackburn wrote:

> I thought it might be helpful to clarify some terminology and a few
> technical issues.  Corrections/improvements/clarifications welcome ;-)
>
> VM core
>
>  The precise composition of the VM core is open to discussion and
>  debate.  However, I think a safe, broad definition of it is that
>  part of the VM which brings together the major components such as
>  JITs, classloaders, scheduler, and GC.  It's the hub in the wheel
>  and is responsible for the main VM bootstrap (bootstrapping the
>  classloader, starting the scheduler, memory manager, compiler etc).
>
> VM bootstrap
>
>  The bootstrap of the VM has a number of elements to it, including
>  gathering command line arguments, and starting the various
>  components (above).
>
>
> In the context of a Java-in-Java VM, the above is all written in Java.
>
>
> VM boot image
>
>  The boot image is an image of a VM heap constructed ahead of time
>  and populated with Java objects including code objects corresponding
>  to the VM core and other elements of the VM necessary for the VM
>  bootstrap (all written in Java, compiled ahead of time, packaged
>  into Java objects and composed into a boot image).  The boot image
>  construction phase requires a working host VM (ideally the VM is
>  self-hosting).
>
> VM bootloader
>
>  In the case of Jikes RVM a dozen or so lines of assember and a few
>  lines of C are required to basically do the job of any boot loader
>  loader---mmap a boot image and throw the instruction pointer into
>  it.  It will also marshal argv and make it available to the VM core.
>  This is technically interesting, but actually pretty trivial and has
>  little to do with the VM core (aside from ensuring the instruction
>  pointer lands a nice place within the boot image ;-)
>
> OS interface
>
>  The VM must talk to the OS (for file IO, signal handling, etc).
>  There is not a whole lot to it, but a Java wrapper around OS
>  functionality is required if the VM is java-in-java.  This wrapper
>  is pretty trivial and one half of it will (by necessity) be written
>  in C.
>
> I hope this brief sketch provides folks with a slightly clearer view
> of what a java-in-java VM looks like, and some (tentitive) terminology
> we can use to ensure we're not talking at cross purposes.
>
> Cheers,
>
> --Steve
>
>


Mime
View raw message