Community
Participate
Working Groups
DTFJ 1.4 has a close method on the image. We should use this to tidy up when a dump is closed. This will delete any temporary DTFJ file more efficiently than forcing a garbage collection and finalization. DTFJ 1.4 has been available since July 2010. Should we make it a requirement for the DTFJ adapter, or should we cope with older versions and catch the NoSuchMethodError? Keeping the old way using System.gc gives a FindBugs warning.
Added a call to close()
I would say that we recommend (wiki?) the use of 1.4. If the effort to keep the tool working with the 1.3 versions is not high, then I think it would be better to keep it working with both. On the other hand I find it fully ok to say that next version of MAT needs the 1.4 version of DTFJ and can't work with the older ones. I think this is up to you then, depending on how much effort it is.
I've checked in the changes, Image.close() is called if available. We needed better counting of Images from the cache as close must only be called after the last use. Normally the snapshot caching stops there being more than one DTFJ Image for the same file, but if the same file is opened with a relative and absolute path then the DTFJ reader can see both opens with the same absolute path. I've added a test case to show this. The general rules are: when an new image is read it is added to the cache (assuming another thread hasn't added it to the cache meanwhile) when an image is obtained from the cache the use count is incremented if the image is returned and it is in the cache then the use count can be decremented. if the returned image is not in the cache, and the cache is empty, it can be put back into the cache, otherwise it can be closed If a new version of an image is needed then the old version in the cache can be tagged so that it will be closed when the use count goes to zero if the plugin is stopped then once the use count goes to zero then the image should be closed I have also added some code to allow selection of the Java runtime if the DTFJ image happened to have multiple runtimes. I haven't seen this yet, so I have followed the lead from HPROF with MAT_HPROF_DUMP_NR and just used an environment variable: -DMAT_DTFJ_RUNTIME_ID=0.0.0 address space number index of process in address space index of runtime in process I have also allowed the ImageFactory to be obtained by a query. It is stored via a weak hash map from the image.
This is now fixed - and the runtime id can also be specified via the preferences.
