harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] jre bundle size
Date Sun, 21 Oct 2007 18:42:36 GMT
On the 0x374 day of Apache Harmony Tim Ellison wrote:
> Alexei Fedotov wrote:
> > Hello Egor,
> > 
> >> Can anyone, please, help me find a microbenchmark where current CU
> >> implementation helps?
> > 
> > Please, check the following tests [1] developed by Nikolay Chugunov.
> > They just report failure when CU is absent.
> > 
> > Thanks.
> > 
> > [1] http://svn.apache.org/viewvc/harmony/enhanced/buildtest/branches/2.0/tests/stress/qa/src/test/stress/org/apache/harmony/test/stress/classloader/unloading/
> 
> Ahhh, CU = Class unloading.  I thought Compilation Unit.  Never mind my
> last post on this thread 8*)

Yeah, I am a _big misleader_, misleading is not even my hobby :)
Sorry again, looks like I saw this CU somewhere (maybe, in Rana's emails)

...i love and hate acronyms

> Tim
> 
> 
> > On 18 Oct 2007 17:53:32 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> >> On the 0x373 day of Apache Harmony Tim Ellison wrote:
> >>> Rana Dasgupta wrote:
> >>>> Even in drlvm we have a lot of dll's, and I am not sure that this is
a
> >>>> bad thing. It allows the components to be more modular and actually
> >>>> can reduce memory footprint, we just have to be more judicious about
> >>>> what we load at startup. We could also drop things like gc_cc.dll etc.
> >>>> if we really need to.
> >>> Certainly helps when there is sharing rather than copying of code/data.
> >>>  And if the DLLs are optional functionality then it allows users to
> >>> customize the runtime that much easier.  For example, the IBM VME can
> >>> tolerate the removal of the JIT DLL such that (obviously) you only get
> >>> the interpreter functionality, same for some diagnostics, etc.  For
> >>> people who want to reduce the disk/in memory footprint they can tailor
> >>> it to suit.
> >>>
> >>>> Not sure why distribution size is a big problem, it is the memory
> >>>> image size that seems more important.
> >>> Ideally we want both of course<g> but I agree that we should plan
to
> >>> distribute the full set of functionality (the big disk option) and allow
> >>> people to remove unwanted function as they see fit.
> >> Can anyone, please, help me find a microbenchmark where current CU
> >> implementation helps? And did anyone experiment with CU effect on
> >> DaCapo performance?
> >>
> >> not suspicious, just interested..
> >>
> >> --
> >> Egor Pasko
> >>
> >>
> > 
> > 
> 

-- 
Egor Pasko


Mime
View raw message