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 Tue, 29 Apr 2008 03:08:16 GMT
On Tue, Apr 29, 2008 at 10:46 AM, Sergey Salishev
<sergey.i.salishev@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 <xiaofeng.li@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
>  > <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
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > http://xiao-feng.blogspot.com
>  >
>



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

Mime
View raw message