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:04:59 GMT
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

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


Mime
View raw message