Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mat-dev] Proposal: do a next release in Dec 2020
Hey Andrew,

> 2020-06 and later requires Java 11 so if we want to run under Java 8 then 2020-03 is the latest.

In my opinion, there should be some more time before MAT requires Java 11. This will require many customers to upgrade their JRE which can be difficult in some locked-down corporate environments.

However, I do think an upgrade to 2020-03 is worth it. In particular, the current build of MAT does not work on macOS with OpenJ9 compressed references builds because Photon does not link with -pagezero_size 0x1000 (the work-around is to use a "large heap" JRE but this has compressed references disabled and is less performant).

Thank you for all your other improvements.

--
Kevin Grigorenko
IBM App Platform SWAT




From:        Andrew Johnson <andrew_johnson@xxxxxxxxxx>
To:        Memory Analyzer Dev list <mat-dev@xxxxxxxxxxx>
Date:        09/24/2020 10:24 AM
Subject:        [EXTERNAL] Re: [mat-dev] Proposal: do a next release in Dec 2020
Sent by:        mat-dev-bounces@xxxxxxxxxxx



> From: "Tsvetkov, Krum"  
>
> Hi,
>
> There have been quite a lot of code changes since MAT 1.10.0 got
> released in March this year.
> I’d suggest that we plan for another release (1.11.0) aligned with
> the Eclipse SimRel.
> Next simultaneous release is 2020-12 with a planned GA date December 16
2020.
>
> So, what do you think – shall we plan for 1.11.0 with a target
> release date Dec. 16, and make it part of SimRel 2020-12?
> If there are no objections, I’d take care of the release activities
> and try to contribute to some early 2020-12 milestones.
>
> Regards,
> Krum
>
Yes, I think it would be useful to release those changes.
Here is a summary of the main ones I've worked on, so I hope
people can test them before the release.

Comparisons
===========

I have made quite a lot of improvements to snapshot comparisons, but
haven't had
much feedback yet on whether we have solved the original problems.

Can we close any of these items, or narrow down what more is needed?
283778: Diff Heap Dumps
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283778
298078: Comparison Features in MAT
https://bugs.eclipse.org/bugs/show_bug.cgi?id=298078
305152: Improvements to the displayed comparison results
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305152
305154: Extend the programming model for MAT Queries - enable programming
of queries doing comparison
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305154
369047: Tracking/Comparing heap dumps
https://bugs.eclipse.org/bugs/show_bug.cgi?id=369047
561460: More comparison queries
https://bugs.eclipse.org/bugs/show_bug.cgi?id=561460

Does my leak suspects by snapshot comparison actually work for real cases?

MacOS builds
============

I have changed the build to sign and notarise the Mac binaries from the
overnight builds.
Does this actually work? I've had some good reports, but I can't test it
myself.
566282: Cannot install on latest MacOS version Catalina 10.15
https://bugs.eclipse.org/bugs/show_bug.cgi?id=566282
550545: MAT macOS binaries should be signed for apple's gatekeeper
https://bugs.eclipse.org/bugs/show_bug.cgi?id=550545

We need to document how to notarise the released binaries.
https://wiki.eclipse.org/MemoryAnalyzer/Contributor_Reference#Simultaneous_release_policies

Base Platform
=============

Should we continue to build on top of Photon (June 2018)?
This gives us these OS versions (with download numbers to 19 September
2020)
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-win32.win32.x86_64.zip
70417
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-macosx.cocoa.x86_64.zip
32683
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-linux.gtk.x86_64.zip 10808
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-win32.win32.x86.zip 7508<=
/mat/1.10.0/MemoryAnalyzer-1.10.0.202002252112.zip  5014
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-linux.gtk.x86.zip   925<=
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-linux.gtk.ppc64.zip 320<=
/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-linux.gtk.ppc64le.zip 132
If we move to 2020-09 we lose Windows 32-bit, Linux 32-bit x86,
Linux ppc64 big-endian, but could gain Linux AArch64
Users would still have the option of installing MAT into a back level
version of Eclipse.

2020-06 and later requires Java 11 so if we want to run under Java 8 then
2020-03 is the latest.

Huge Heaps
==========
I added an option to cope with huge heaps >2^31 objects or taking more
space
that MAT can run with. This works by discarding a percentage of the
objects,
but with the hope the leak is still visible. Does this actually work?
Is the documentation sufficient?

Improvements to reports
=======================
Show stack frame and key local variables involved with a leak.
Merge paths from GC roots now has a context menu for the object and the
referenced objects.
These appear in the report for the reference pattern for multiple leak
objects.
Also help updates.

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

_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mat-dev



Back to the top