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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > > > > > > > > > > http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel > > > > > > > > > -- > http://xiao-feng.blogspot.com >
