Heapdump indexed on pre-1.16 fails to open on 1.16

[jasonk000]

Specifically -- an index created on 1.16 cannot be opened on pre-1.16 and triggers re-indexing, likely related to #63.

(I am guessing the reverse also applies, where an old index could not be opened on 1.16).

Seems that the parsing stage. uses ObjectInputStream, which uses reflection to set the ClassImpl.subClasses to a List which it previously was in the old serialized form, to a Set (which it is in the updated implementation).

[Begin task] Reopening parsed heap dump file
[WARNING] Reparsing heap dump file due to cannot assign instance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
java.io.IOException: cannot assign instance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
at org.eclipse.mat.parser.internal.SnapshotImpl.readFromFile(SnapshotImpl.java:273)
at org.eclipse.mat.parser.internal.SnapshotFactoryImpl.openSnapshot(SnapshotFactoryImpl.java:178)
at org.eclipse.mat.snapshot.SnapshotFactory.openSnapshot(SnapshotFactory.java:149)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl$ProviderImpl.lambda$provide$0(HeapDumpAnalyzerImpl.java:1970)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl.$(HeapDumpAnalyzerImpl.java:189)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl$ProviderImpl.provide(HeapDumpAnalyzerImpl.java:1966)
at org.eclipse.jifa.hdp.provider.HeapDumpAnalysisApiExecutor.buildAnalyzer(HeapDumpAnalysisApiExecutor.java:190)
at org.eclipse.jifa.hdp.provider.HeapDumpAnalysisApiExecutor.buildAnalyzer(HeapDumpAnalysisApiExecutor.java:43)
at org.eclipse.jifa.analysis.AbstractApiExecutor.lambda$buildAnalyzer$3(AbstractApiExecutor.java:238)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)

Caused by: java.lang.ClassCastException: cannot assign instance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2096)
at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2060)
at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1347)
at java.base/java.io.ObjectInputStream$FieldValues.defaultCheckFieldValues(ObjectInputStream.java:2679)
at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2486)
at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at org.eclipse.mat.collect.HashMapIntObject.readObject(HashMapIntObject.java:481)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1100)
at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2423)
at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at org.eclipse.mat.parser.internal.SnapshotImpl.readFromFile(SnapshotImpl.java:208)
... 11 more

[jasonk000]

I am thinking there might be a few approaches here,

1. Do nothing, and add an errata/note.

2. The simplest solution to allow 1.16 to continue opening old index files might be to change Set to Collection. This does not solve the issue of pre-1.16 versions opening a 1.16 index.

3. Revert the change to store the implementation as a List, and introduce a transient field being a Set, which could be used to accumulate values. We must also introduce then a marker/stamp that if the Set is ever changed, the List will need to be regenerated for reading.

[kgibm]

I just hit this problem. This could be a significant issue. For example, our support organization often receives customer dumps that are huge and take about a day to parse; then, they're subsequently re-opened multiple times as the dump is sent between various teams or engineers re-open them on a new working day (we use remote systems through Citrix which are sometimes rebooted over night). This will make transitioning to MAT 1.16 pretty painful in a non-trivial amount of instances. If it's not too much effort, it would be nice if you can add backwards compatibility. I think the issue of a pre-1.16 version trying to open a 1.16 index is not a common issue.

[jasonk000]

@kgibm , I wonder if you can take a look at this early draft? #91

I still need to build/test/verify.