[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mat-dev] GarbageCleaner phase code
|
> Hi all,
>
> Looking for some input on suitability to raise a bug and submit this
> change. If you can advise any additional specific tests to run I
> will be happy to build them out and execute them..
>
> Results on a 73GB file over 5 runs on a 48GB 8+8cores machine are
> here, in brief it is 2-4x faster for large heaps:
> https://gist.github.com/jasonk000/9f31e2446a84b56f11d494c146969e7b
>
> I understand that my last round of commits required an additional
> pass of discussion on memory footprint. I believe the memory
> footprint here would be reduced as it merges the maps during
> generation (C maps, scaling to C cores) vs previous approach (N
> maps, when the processing was split into N chunks and scaled to
> object heap). All existing functional tests work ok.
>
> There are a sequence of five commits presented here:
> https://github.com/jasonk000/eclipse-mat/compare/gc-opt
>
> Thanks
> Jason_______________________________________________
This looks like a useful improvement. I don't have any tests in mind,
but do look at the previous changes to GarbageCleaner.java and what
defects led up to the change.
Tests are useful, but with multi-threaded code then reviews of the
code are also important as defects will not be as reproducible.
For example the change to
if (ref != null && ref.get() != null)
{
return ref.get();
could cause problem as the soft reference could be cleared between
the two get() calls.
Sometimes a test mode - with more threads or large / smaller
buffers, or a constrained heap, or a very large heap dump with
nearly 2G objects can help find bugs.
Do other people have comments?
Andrew Johnson
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU