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 19:36:55 GMT
On the 0x376 day of Apache Harmony Egor Pasko wrote:
> On the 0x375 day of Apache Harmony Rana Dasgupta wrote:
> > Same as Tim :-) I didn't quite get the class unloading question on
> > this thread. Possibly Egor is thinking about footprint reduction.
> 
> Egor is definitely thinking about FR :)))
> 
> Rana,
> 
> 1. I am very glad that there are tests that do not pass without class
>    unloading (as Alexei Fedotov pointed out, ehm, my respect)
> 
> 2. I did not see anyone who checked class unloading on DaCapo, so I
>    did it myself. I checked release build in two modes:
> 
> A) -Xem:server
> B) -XX:gc.ignore_vtable_tracing=false -XX:gc.force_major_collect=true -Xem:server
> Ubuntu 6.06.1 LTS on my laptop

forgot to mention: r586906

> most of timings varied within 6% which is, I guess, in the noise level
> of this benchmark and my awful environment with lots of services running
> 
> but, to the *unpleasant* surprize sadly hsqldb takes 15% more time to
> finish on (B). This answers the question why we may not want to enable
> class unloading by defeult yet, right?
> 
> Rana, is it easy to find out what the heck is happening with this
> hsqldb? Maybe some perf gurus can fire up several dosens of ideas on it? :)
>
> > Egor, in JIRA issue 4477, there is a test that needs unloading to succeed.
> > 
> > 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
> 
> 

-- 
Egor Pasko


Mime
View raw message