You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@harmony.apache.org by Johnny Kewl <jo...@kewlstuff.co.za> on 2008/03/01 23:11:40 UTC

JRE Lite

TIm... you right too much in one topic so split...

You know when you discovering something, its not a science, its exploration, and I havent even got
the dev env going yet so still very low on the learning curve... but this is what I'm thinking..

The basic JRE engine must be completely plugable... dynamic loading as you call it.
At a quick glance the really big components are things like the JIT compiler,
The fonts, all the "base" classes and the Unicode... I think its a unicode module.

Now here is what I'm thinking... the JRE gets stripped right down...
So for example it looks for JIT but if it cant find it is doesnt crash.

Then instead of making users download... there is a Harmony site and on this site, are all the fonts, all the classes... optional UTF modules etc etc.

The initial download is just a bootstrap... it can either be downloaded or included with the software...
If it needs a Comic font and UTF module... it fetches it, just enuf to get that application running.
So if the users runs a series of small applications they all very quick installs, but the JRE is growing...
So by the time the user installs a heavy application, the JRE will probably do it all.

In this scheme there is also no concept of versioning... if a class is loaded that needs a new JRE lite module
it will just happen.... the user is hassle free.

So there is still a installation server somewhere.... but the user doesnt even have to know about it.
That kind of dynamic loading means the JRE must fit together like a jigsaw puzzle..

For example the first run of an application may run without JIT, but the JRE's background loader starts to pull
it down... the next run will be fast....

The reason I asked about the interchangability is because if one has a small engine that can get only what it has to... then that gets very interesting.
For example, if a machine already has classpaths all over the place.... and a JavaLite hits the machine.... it gets only what it needs, ie it gets
a few core classes, maybe a few fonts, maybe its own multimedia engine.... but it does not have to get anything else... it does not have
to tell the users to setup xerces again... it see's wots on the machine already and uses it... so theres the compatability side... the creativity
side is that the Java application downloaded, may also be able to suck down a native module, or custom class modules that do stuff like play
Flash Video... now thats a JRE ;)

So... when I get going I'm going to break Harmony into tini weenie pieces.... ha ha.
In this model, one does not even care about classes.... its just that engine that must be able to discover and use whats there, or pull it from a installation server.
Apps have the choice of using there own JRE Lite... or the systems JRE ;) but I think if that JRELite is small enuf... it will go out with every application.
Installers will use that... for sure, it makes life very easy.

... so thats the idea... whether it will pan out, and the idea is possible, I dont know... I cant see why not....

Some application will be unlucky... they internationalized the developer has gone mad with XML, use JPA, JMX, JWhatever... and yes that
apps JRE will have to build itself up to 10 megs before it will run... but a game using JNI and doing its own drawing will probably run on a 500k JRE

Developers will very quickly learn what make the JRE take a big hit.... I think thats a good thing, all the technology is there but depending on what
system they targeting.... they will design accordingly, possibly using property files instead of XML parsing...

So... once I get going thats my hobby for the next 4 months ;)
If it works... you'll have to make another SVN fork;)

Re: JRE Lite

Posted by Xiao-Feng Li <xi...@gmail.com>.

On Tue, Apr 29, 2008 at 10:46 AM, Sergey Salishev
<se...@gmail.com> wrote:
> Hi Xiao-Feng,
>
>  I wrote mostly about RE JRE. Harmony currenty lacks both features - class
>  data sharing and kernel distribution. The 3MB statement is only an
>  interpretation of the Alexey's link abount the new distribution mode of 6u10
>  release.
>
>  I think *HARMONY-5513* <https://issues.apache.org/jira/browse/HARMONY-5513>
>  covers the class data sharing feature for Harmony, but it's closed.

Ok, I see. We may want to contact the JIRA reporter checking if he
still has any patch available for POC, even not applicable.

Thanks.
xiaofeng

>  Thanks.
>  Sergey.
>
>
>
>
>  On Tue, Apr 29, 2008 at 3:41 AM, Xiao-Feng Li <xi...@gmail.com> wrote:
>
>  > Sergey, interesting comments. Startup is surely a topic that should be
>  > addressed. Your comments are helpful.
>  >
>  > I am not very sure about the footprint. Does Harmony have a solution
>  > for small footprint?  What is "With the Kernel distribution it's only
>  > 3MB"? Thanks.
>  >
>  > -xiaofeng
>  >
>  > On Tue, Apr 29, 2008 at 3:17 AM, Sergey Salishev
>  > <se...@gmail.com> wrote:
>  > > Hi,
>  > >
>  > >  Alexey, thanks for the link. I don't think the distribution size is the
>  > >  biggest JRE problem for client applications. Anyway even without Kernel
>  > >  distribution RE JRE is only 15MB which is substantially smaller than
>  > .NET
>  > >  framework redistributable. With the Kernel distribution it's only 3MB
>  > about
>  > >  2x Flash Player size :)
>  > >
>  > >  JRE's three biggest problems I think are slow startup, large footprint
>  > and
>  > >  GC pauses. The footprint problem is generally solved by data sharing
>  > between
>  > >  JVM instances. The GC pauses can be helped by using incremental or
>  > >  concurrent GC.
>  > >
>  > >  The startup time tougher problem. It's almost unrelated to the
>  > ditribution
>  > >  size as only the used classes are loaded. But it's governed by the
>  > class
>  > >  parsing and no-opt JIT/interpreter overhead. It's possible to make JRE
>  > >  startup to be more lean and mean. But the real answer here is excluding
>  > the
>  > >  classloading and JIT phase from startup altogether at least for
>  > frequently
>  > >  used components.  The good news are that most of the frequently used
>  > classes
>  > >  for small applications are located in class libraries. RE JRE as I
>  > remember
>  > >  already can precompile rt.jar and use that fact. .NET has a signed
>  > binary
>  > >  module cache and the application installer can compile the model AOT
>  > and
>  > >  place it to cache.
>  > >
>  > >  The bbiggest  problems of AOT compiled module caching are class
>  > versioning
>  > >  and security. I think it's possible to implement such mechanism for
>  > Java
>  > >  using Jar files as an atomic modules for AOT caching. In this case the
>  > Jar
>  > >  signature would be used for module versioning and ensuring the binary
>  > code
>  > >  is unmodified. We already made some experiments and caching on
>  > individual
>  > >  method level doesn't give any performance boost due to class loading
>  > and
>  > >  signing overhead.
>  > >
>  > >  Thanks.
>  > >  Sergey.
>  > >
>  > >  2008/4/28 Alexey Petrenko <al...@gmail.com>:
>  > >
>  > >
>  > >
>  > >  >
>  > >  >
>  > http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > http://xiao-feng.blogspot.com
>  >
>



-- 
http://xiao-feng.blogspot.com

Re: JRE Lite

Posted by Sergey Salishev <se...@gmail.com>.

Hi Xiao-Feng,

I wrote mostly about RE JRE. Harmony currenty lacks both features - class
data sharing and kernel distribution. The 3MB statement is only an
interpretation of the Alexey's link abount the new distribution mode of 6u10
release.

I think *HARMONY-5513* <https://issues.apache.org/jira/browse/HARMONY-5513>
covers the class data sharing feature for Harmony, but it's closed.

Thanks.
Sergey.


On Tue, Apr 29, 2008 at 3:41 AM, Xiao-Feng Li <xi...@gmail.com> wrote:

> Sergey, interesting comments. Startup is surely a topic that should be
> addressed. Your comments are helpful.
>
> I am not very sure about the footprint. Does Harmony have a solution
> for small footprint?  What is "With the Kernel distribution it's only
> 3MB"? Thanks.
>
> -xiaofeng
>
> On Tue, Apr 29, 2008 at 3:17 AM, Sergey Salishev
> <se...@gmail.com> wrote:
> > Hi,
> >
> >  Alexey, thanks for the link. I don't think the distribution size is the
> >  biggest JRE problem for client applications. Anyway even without Kernel
> >  distribution RE JRE is only 15MB which is substantially smaller than
> .NET
> >  framework redistributable. With the Kernel distribution it's only 3MB
> about
> >  2x Flash Player size :)
> >
> >  JRE's three biggest problems I think are slow startup, large footprint
> and
> >  GC pauses. The footprint problem is generally solved by data sharing
> between
> >  JVM instances. The GC pauses can be helped by using incremental or
> >  concurrent GC.
> >
> >  The startup time tougher problem. It's almost unrelated to the
> ditribution
> >  size as only the used classes are loaded. But it's governed by the
> class
> >  parsing and no-opt JIT/interpreter overhead. It's possible to make JRE
> >  startup to be more lean and mean. But the real answer here is excluding
> the
> >  classloading and JIT phase from startup altogether at least for
> frequently
> >  used components.  The good news are that most of the frequently used
> classes
> >  for small applications are located in class libraries. RE JRE as I
> remember
> >  already can precompile rt.jar and use that fact. .NET has a signed
> binary
> >  module cache and the application installer can compile the model AOT
> and
> >  place it to cache.
> >
> >  The bbiggest  problems of AOT compiled module caching are class
> versioning
> >  and security. I think it's possible to implement such mechanism for
> Java
> >  using Jar files as an atomic modules for AOT caching. In this case the
> Jar
> >  signature would be used for module versioning and ensuring the binary
> code
> >  is unmodified. We already made some experiments and caching on
> individual
> >  method level doesn't give any performance boost due to class loading
> and
> >  signing overhead.
> >
> >  Thanks.
> >  Sergey.
> >
> >  2008/4/28 Alexey Petrenko <al...@gmail.com>:
> >
> >
> >
> >  >
> >  >
> http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel
> >  >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>

Re: JRE Lite

Posted by Xiao-Feng Li <xi...@gmail.com>.

Sergey, interesting comments. Startup is surely a topic that should be
addressed. Your comments are helpful.

I am not very sure about the footprint. Does Harmony have a solution
for small footprint?  What is "With the Kernel distribution it's only
3MB"? Thanks.

-xiaofeng

On Tue, Apr 29, 2008 at 3:17 AM, Sergey Salishev
<se...@gmail.com> wrote:
> Hi,
>
>  Alexey, thanks for the link. I don't think the distribution size is the
>  biggest JRE problem for client applications. Anyway even without Kernel
>  distribution RE JRE is only 15MB which is substantially smaller than .NET
>  framework redistributable. With the Kernel distribution it's only 3MB about
>  2x Flash Player size :)
>
>  JRE's three biggest problems I think are slow startup, large footprint and
>  GC pauses. The footprint problem is generally solved by data sharing between
>  JVM instances. The GC pauses can be helped by using incremental or
>  concurrent GC.
>
>  The startup time tougher problem. It's almost unrelated to the ditribution
>  size as only the used classes are loaded. But it's governed by the class
>  parsing and no-opt JIT/interpreter overhead. It's possible to make JRE
>  startup to be more lean and mean. But the real answer here is excluding the
>  classloading and JIT phase from startup altogether at least for frequently
>  used components.  The good news are that most of the frequently used classes
>  for small applications are located in class libraries. RE JRE as I remember
>  already can precompile rt.jar and use that fact. .NET has a signed binary
>  module cache and the application installer can compile the model AOT and
>  place it to cache.
>
>  The bbiggest  problems of AOT compiled module caching are class versioning
>  and security. I think it's possible to implement such mechanism for Java
>  using Jar files as an atomic modules for AOT caching. In this case the Jar
>  signature would be used for module versioning and ensuring the binary code
>  is unmodified. We already made some experiments and caching on individual
>  method level doesn't give any performance boost due to class loading and
>  signing overhead.
>
>  Thanks.
>  Sergey.
>
>  2008/4/28 Alexey Petrenko <al...@gmail.com>:
>
>
>
>  >
>  > http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel
>  >
>



-- 
http://xiao-feng.blogspot.com

Re: JRE Lite

Posted by Sergey Salishev <se...@gmail.com>.

Hi,

Alexey, thanks for the link. I don't think the distribution size is the
biggest JRE problem for client applications. Anyway even without Kernel
distribution RE JRE is only 15MB which is substantially smaller than .NET
framework redistributable. With the Kernel distribution it's only 3MB about
2x Flash Player size :)

JRE's three biggest problems I think are slow startup, large footprint and
GC pauses. The footprint problem is generally solved by data sharing between
JVM instances. The GC pauses can be helped by using incremental or
concurrent GC.

The startup time tougher problem. It's almost unrelated to the ditribution
size as only the used classes are loaded. But it's governed by the class
parsing and no-opt JIT/interpreter overhead. It's possible to make JRE
startup to be more lean and mean. But the real answer here is excluding the
classloading and JIT phase from startup altogether at least for frequently
used components.  The good news are that most of the frequently used classes
for small applications are located in class libraries. RE JRE as I remember
already can precompile rt.jar and use that fact. .NET has a signed binary
module cache and the application installer can compile the model AOT and
place it to cache.

The bbiggest  problems of AOT compiled module caching are class versioning
and security. I think it's possible to implement such mechanism for Java
using Jar files as an atomic modules for AOT caching. In this case the Jar
signature would be used for module versioning and ensuring the binary code
is unmodified. We already made some experiments and caching on individual
method level doesn't give any performance boost due to class loading and
signing overhead.

Thanks.
Sergey.

2008/4/28 Alexey Petrenko <al...@gmail.com>:

>
> http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel
>

Re: JRE Lite

Posted by Alexey Petrenko <al...@gmail.com>.

http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel