On Tue, Apr 29, 2008 at 10:46 AM, Sergey Salishev <[EMAIL PROTECTED]> 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 <[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 > > > -- http://xiao-feng.blogspot.com
