harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: JRE Lite
Date Mon, 28 Apr 2008 23:41:22 GMT
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.


On Tue, Apr 29, 2008 at 3:17 AM, Sergey Salishev
<sergey.i.salishev@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 <alexey.a.petrenko@gmail.com>:
>  >
>  > http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel
>  >


View raw message