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 22:00:58 GMT
On the 0x377 day of Apache Harmony Rana Dasgupta wrote:
> 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.

Oh, Rana, thanks for your explanation! Now it becomes clearer and
clearer. Indeed, -XX:gc.ignore_vtable_tracing=false does _not_ slow
things down, all slowdown comes from enabling full heap collections
each time.

I agree that testing the implementation is not very pleasant thing to
do and falls into two parts:

1. test that heap size is reduced
2. test that no major slowdown happens

to test (1) I can see: 

1.a) as you mentioned, make a stress test with real lots of unused
classloadings, so that they won't fit into -Xmx 128m that we set,
check that OoutOfMemory does not happen. (I suspect somebody invented
it already:) Do we trigger GC before actual exception is thrown?

1.b) output classunloaded size to some debug stream and count the
  total size on either some big benchmark/scenario or a stress test

1.c) periodically check heap size via OS on some long running
  scenario, compare the two charts

1.d) to make results more verbose either catch and find out how many
  times and when the full collection happened or, as you do, run the
  full collection always (only for testing purposes)

the (2) is more sensitive, but 1.d should work pretty good here too,
    we just need to test both cases: "many classes to unload", "no
    classes to unload"

How does it sound?

Anyway, looking at how class unloading is reported to performs on
microtests, DaCapo, SPEC, I can already say: well done!

(still one suggestion: ignore_vtable_tracing -> do_vtable_tracing,
sometimes I just feel my brains are overloaded by lots of negations in
one place)


> 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
> >
> >
> 

-- 
Egor Pasko


Mime
View raw message