I managed to get locally a 2020-03-based build (including tests). This might be a good first step, and we could still discuss if we try to move to a newer one now or wait in order to avoid requiring Java 11.
I created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=567414 to track the update. Let’s move the discussion there.
From: "Tsvetkov, Krum" <krum.tsvetkov@xxxxxxx>
Date: Monday, 28. September 2020 at 11:04
To: Memory list <mat-dev@xxxxxxxxxxx>
Subject: Re: [mat-dev] Proposal: do a next release in Dec 2020
Hi,
I was actually working on building the standalone packages with 2020-09. I got a working installation – there were not many changes needed, but it was tricky to find what has to be adapted :) Also, I still can’t get
the tests to run, but I guess this is only a matter of time.
If a dependency on Java 11 is a big concern, I guess I’d be able to get a build with 2020-03. On the other hand, even if we go with 2020-09, there will be workarounds to stay with Java 8 – install MAT features into an
IDE, or install MAT 1.10 and update the MAT parts only from the new update side (we might need to document these options if we put a requirement on Java 11).
WDYT? Go for the latest and greatest and document how to avoid installing Java 11, or build with (at the time of the release) 9 months older Eclipse parts?
@Andrew – thanks for the many improvements! After some position changes I rarely do heap dump analysis as part of my daily job. I’ll see if I can still provide you reasonable feedback on some of the changes.
Regards,
Krum
From: <mat-dev-bounces@xxxxxxxxxxx> on behalf of Kevin Grigorenko
Reply to: Memory list <mat-dev@xxxxxxxxxxx>
Date: Friday, 25. September 2020 at 16:34
To: Memory list <mat-dev@xxxxxxxxxxx>
Subject: 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
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