harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)
Date Tue, 06 Dec 2005 15:44:57 GMT
Dalibor Topic wrote:
>>There is a core set of classes required to bootstrap the OSGi framework
>>code.  The trick is to bring up enough classes to implement the
>>framework, then retrospectively apply the framework rules to those
>>classes.  By the time the framework is instantiated and ready to load
>>new classes it will have the core classes installed.
> 
> I've had something like that in mind, too, cool.
> 
> Is it absolutely necessary to have those core classes as a bundle, and
> do the retrospective trick?

No it's not.  It's desirable because then you get the benefits of
componentization across the entire class library, but it is not
absolutely necessary.

If the core classes are declared in bundles then dependent bundles can
verify the version compatibility of the core classes, and in turn core
class bundles can be excluded from reaching into the non-API areas of
core, etc.

> I'm trying to figure out if we can shave off complexity, so please bear
> with my basic knowledge of OSGi semantics :)

The additional complexity may be as simple as requiring the VM to
support changing a class' class loader.  When the framework is being
brought up the core classes will be loaded by the bootstrap class loader
(which is typically known by the VM).  When the framework is defined and
initializing those core classes will be moved to framework-defined class
loaders (to enforce visibility rules).

There are other approaches that are not so naive, but you get the idea.

>>IMHO the framework requires too many classes for this to double as the
>>VM interface -- the number of classes that the VM knows intimately is
>>much smaller, and what I have been calling the 'kernel' classes (about
>>18 or so types).  The kernel classes can be written as a bundle
>>(fragment) that plays in the class componentization model alongside LUNI
>>(java.lang, java.util, java.net, java.io), SECURITY, etc.
> 
> OK. I see how one can, by programming carefully, knock things down to a
> very small, minimal set of classes necessary. I don't think we have to
> absolutely strive for the absolute minimum, though, as it may end up
> making the interface more complicated and less useful in practice for a
> few reasons:
> 
> a) people implementing the interface on their own VMs may find out that
> it relies too closely on correct order of class loading for them to
> easily bootstrap their not fully standard conforming VMs. Ahem. :)
> 
> b) Minimizing the set of bootstrap classes can result in complexity
> being pushed out somewhere else, for example by mandating native methods.

Just to be clear, the kernel classes are VM-dependent types that are not
typically reusable since the VM typically will 'know' the shape of the
class/instances.  I think it is useful to minimize that set.

The set of classes required to run an OSGi framework is a superset of
kernel; and of course there are a number of meaningful supersets
reaching up from there.  I proposed the boundaries for those as the
functional units of JSE, as defined on the wiki.

The mix-n-match approach works top-down just as well as bottom-up:

bottom-up:
  If you implement a VM with the minimal VM Interface (kernel classes +
vmi.h) then you can reuse all of the remainder of the Harmony classlib code.

top-down:
  If you develop an alternative implementation of some component, say
java math, then by including the packages declared in the
componentization proposal, and declaring it to be an OSGi bundle, you
can confidently provide it as a drop-in replacement to the java math
bundle in Harmony class libs.

Componentization gives you benefits at development time (e.g. explict
exports allow you to evolve the implementation with a well-managed SPI
to other bundles), and at runtime (e.g. explicit imports allow you to
co-exist with other bundles that require different versions of the same
bundle).

There is no harm at all in VMs having dependency requirements on a
particular set of bundles based on their capabilities.

> Considering that we have 4000-5000 classes in 1.5 to work with, I
> believe the difference between an 18 class bootstrap interface and a 50
> class bootstrap interface is negligible, given that, as I explained
> below, most people are either able to pick various open source
> implementations of a large set of those classes under licenses ranging
> from BSD, ASLv2, GPL+linking exception, to LGPL, and GPL, to name a few,
> and mix and match those largely to their heart's content.

Absolutely, people can bootstrap with whatever they use today, then use
components from Harmony or Classpath that are higher in the SE stack.
Mmmm, harmony.

The Java code is likely to be quite easy to split apart into components,
the native code may need massaging to be built into a separate lib to
make the component stand-alone.  And if you want the component to work
on a Hy-compatible VM the only dependencies on the VM from your code
must be (you guessed it) through the JNI, or VMI, or Kernel classes.

> So if stuffing a class into the bootstrap set helps up reduce the VM
> interface complexity, I'd say let's go for it. Examples below.

<snip>

> Here are my examples of reducing complexity by adding classes to the
> bootstrap set: I see that the interface specifies fdlibm, which I assume
> is needed to properly implement double/float. Rather than specifying an
> interface in C with JNI and all that fun, let's just make Double and
> Float implementations part of the bootstrap set.

fdibm is just an artifact of the existing implementation, not part of
the VMI -- so you get Double and Float for free (i.e. VMs don't have to
make any concession to how they are implemented).

You may prove me wrong now, but are there any VMs targetting JSE that
don't do JNI?  The deal is, if you can do JNI, grok the VMI(*), and you
implement the kernel classes then the remainder of the class libraries
will work.

(*) Note: the HyPortLib and HyZipCachePool defined in the Doxygen doc
are provided in the Hy classlib code.  The functions the VM has to
provide are pretty simple.

> Same with zlib: I didn't see it being specified in OSGi/Minimal, so I
> guess we may be able to get by and say that java.util.zip is either part
> of the bootstrap set, and then we chuck it in, and all the native
> dependencies disappear. There are various java.util.zip implementations
> out there, etc, etc.

Same story, either you play the VMI game and reuse what is in Hy, or you
provide an alternative implementation of the ARCHIVE component (contains
JAR and Zip support).

> In essence, I'd like to see if we can do away with the JNI methods and
> the C part of the VM interface, by enlarging the bootstrap set by those
> classes that would need them, and just leaving their internals unspecified.
> 
> That would mean that the vmi.h and friends are useful for runtimes using
> Harmony's classes, just as the GNU Classpath interface is useful for
> runtimes using those classes, and so on. The overarching VM interface
> could abstract away from those, I hope.

If we raise the semantic level far enough Classpath and Harmony are
bound to be able to interoperate at some level <g>

<snip>

>>Of course, VMs could choose to implement any superset of the kernel
>>classes that suit them, or implement the kernel classes in any manner
>>that suits them (e.g. the earlier discussion of delegates vs. in-lines I
>>think is irrelevant if we agree it is the VM's perogative).
> 
> 
> Yup. Amazing how much simpler things become but just assuming they are
> there. We don;t have to wrestle with the right way to write inlineable
> code, yay :)
> 
> As I said above, I don't think we need to strive for absolute
> minimalism, though. I'd trade an interface that I can implement on a
> lazy weekend for an interface that saves me 200k of kernel classes
> download, but takes me a month to get written. Simpler interface ->
> faster, easier adoption, I hope.

Take a look at the interface and how much is already implemented for
you, and let me know if you think it is not a lazy weekend job.  The
Doxygen includes all the code that is in the Hy codebase already -- I
guess it would be helpful to have a step-by-step guide of what a VM
needs to do.

<snip>

> Great, we are in violent agreement! Someone make a picture! :)

I think so -- though I've probably confused things by talking about the
VMI and talking about class lib componentization in a single thread.

The summary is :
 (1) we should aim for complimentary classlib componentization to get
interop of large functional units;
 (2) VMs wanting to run all the Hy classlib code can do so provided they
have a lazy weekend to spare.

> p.s. you know that after talking about all this stuff for the next week,
> I'll drag you come for FOSDEM to give us an introduction into how it all
> fits together, and why, and so on.

You'll have to translate that paragraph for me -- I can't parse it ;-)


Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message