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 <[EMAIL PROTECTED]> 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
