There isn't much space for plugability of components beyond compile-link
time. And I see no reason to have it otherwise.
Rodrigo
On 5/24/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:
>
> >
> > * "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.
>
> I'm really hoping we can shelve the idea of having a C implementation
> and a Java implementation. I think we should try to mix them into
> one solution.
>
> >
> > 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?
>
> I'll preface this and state that I have no idea what I'm talking
> about. That said, this reminds me a little of what was done in the
> Geronimo architecture that makes it differ from component
> architectures that use central mechanisms like JMX to let modules/
> components communicate. With Geronimo, the components are given
> references to their dependencies, rather than having them work
> through the central bus to talk between dependencies. This gives a
> big speedup, as the overhead goes away. (Ok, there are 'smart'
> proxies between the components, but that's a detail we can ignore here.
>
> I've guessed (and steve confirmed) that the boundaries between the
> modules in a VM aren't "flat" APIs, but something thicker, with a
> good bit of interdependency. So I'd guess that while a central hub
> would be used to let the modules resolve dependencies (The JIT needs
> to talk to the GC and vice versa), it would be something on the order
> of asking the 'hub' (won't use 'core') for something, and getting an
> object back that could be as sophisticated as needed.
>
> I'd sure like to see some of the existing thinking on this from the
> JikesVM peeps....
>
> As an aside to my aside, Ben and I were musing over ways to do things
> like this, because we thought that in a multi-language-capable VM,
> you'd probably define some minimum interface APIs so that parts in
> different languages would have framework support for
> intercommunication, but also provide a "discovery" mechanism to so
> that like-minded components could talk in a more private, direct way.
>
> For example, suppose we are able to define the boundary between GC
> and JIT in a nice way, we'd want any object claiming to be a JIT to
> support that standard API and be able to provide an to the hub to be
> given to any other module an implementation of that interface. So
> you could do any kind of JIT implementation or experimentation and
> plug it in.
>
> However, if I wrote both the JIT and GC, I would want my JIT and GC
> to discover that and give each other a "private" API that took
> advantage of each other's internals. Something like what we used to
> do with COM and "QueryInterface", starting with something basic and
> standard, and grubbing around in it to find something better.
> Loosely speaking :
>
>
> interface Discovery {
> Object queryInterface(UUID interfaceID);
> }
>
> interface JIT extends Discovery {
> // JIT API here
> }
>
> So in my GC implementation, an init() call that's involved when it's
> being created :
>
> void init(Discovery hubDiscovery) {
>
> JIT commonJIT = (JIT) hubDiscovery.queryInterface
> (UUID_FOR_STANDARD_JIT_API);
>
> // now lets see if this JIT knows the secret handshake
>
> CustomJIT goodJIT = (JIT) commonJIT.queryInterface
> (UUID_FOR_JIT_I_ALSO_WROTE);
>
> if (goodJIT != null) {
> ....
> }
> }
>
>
> and in my JIT implementation :
>
> Object queryInterface(UUID id) {
>
> if (UUID_FOR_STANDARD_JIT_API.equals(id)) {
> return this;
> }
>
> if (UUID_FOR_JIT_I_ALSO_WROTE.equals(id)) {
> return myInternalCustomJIT;
>
> return null;
>
> }
>
>
> Anyway, this reminded me of what Ben and I were talking about a few
> days ago. Note that a) I'm just making this up, b) all the above is
> trying to capture some loose ideas on the subject, and c)
> <disclaimer> is all done pre-coffee in a strange hotel room after
> waking up </disclaimer>
>
> geir
>
>
>
>
>
> >
> >
> > -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
> >>
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> [EMAIL PROTECTED]
>
>
>
