harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [general] jre bundle size
Date Sun, 21 Oct 2007 20:46:01 GMT
Egor,
   I will check hsqldb, thanks for trying it out. One of the problems
with peformance runs on CU is that with options like
XX:gc.force_major_collect=true we are asking every collection to be a
major ( full heap )collection, which is bad for performance. This
would explain eg., your 6% loss across the board.
   As such, for class unloading, we do not need this option. But our
CU is designed to be initiated on full collections only, when there is
heap pressure, not on minor collections. But that is not easy to test.
Most of the simpler CU tests we have( eg, the one I pointed ), are
designed to fail if CU does not happen after invoking System.GC(). An
ideal test would be a stress that loads a lot of classes and discards
them, for which this artifical option would not be needed. By design,
the performance impact of CU is expected to be small( in the shadow of
full heap collections ). But it would be nice to prove it.

Rana

On 21 Oct 2007 23:04:59 +0400, Egor Pasko <egor.pasko@gmail.com> 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
>
> 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