RFR: 8275775: VM.metaspace prints flag 'f' for classes that have non-trivial finalize() [v3]

[Ioi Lam]

On Wed, 27 Oct 2021 01:30:37 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Some customers want to observe which loaded classes have overridden the finalize() method. I found that VM.metaspace can output detailed classes. It seems feasible to add 'f' flag to it. With this patch, I found that ZipFileSystem left a finalize after applying this patch, which was obsolete 5 years ago, maybe we should remove it?
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 2/11/2021 7:55 am, David Holmes wrote:
> 
> > On 1/11/2021 5:19 pm, Yi Yang wrote:
> > > On Wed, 27 Oct 2021 01:30:37 GMT, Yi Yang <yyang at openjdk.org> wrote:
> > > > > Some customers want to observe which loaded classes have overridden
> > > > > the finalize() method. I found that VM.metaspace can output detailed
> > > > > classes. It seems feasible to add 'f' flag to it. With this patch, I
> > > > > found that ZipFileSystem left a finalize after applying this patch,
> > > > > which was obsolete 5 years ago, maybe we should remove it?
> > > > 
> > > > 
> > > > Yi Yang has updated the pull request incrementally with one
> > > > additional commit since the last revision:
> > > > ?? typo
> > > 
> > > 
> > > Hi David,
> > > > Do we have sufficient class information to combine with the
> > > > finalize() status, remembering that we will be reporting on every
> > > > single class, to make VM.classes worthwhile? Would a simple command
> > > > to list all non-trivially-finalizable classes be useful in itself?
> > > > VM.finalizable_classes?
> > > 
> > > 
> > > VM.finalizable_classes seems to be too ad-hoc. The only purpose is to
> > > print the class that has non-trivial finalize() method. If, maybe one
> > > day in the future, we want to know which classes have miranda method,
> > > we may need to add another VM.miranda_classes command. VM.classes can
> > > print detailed information of all loaded classes of the JVM, which
> > > looks more extensible and flexible.
> > 
> > 
> > My concern is there will be too much information to be useful if you
> > simply list and flag every single loaded class. We are basically trying
> > to make a decision whether to add a command that asks a specific query
> > (show me all finalizable classes), versus a command that just produces a
> > class dump and the user then has to manually apply their query to that
> > raw data. There are pros and cons to each approach.
> 
> It has been pointed out (thanks Alex) that we already have VM.class_hierarchy to print all classes, so perhaps that could be augmented to add a decorator for finalizable classes?
> 
> David
> 
> > This also seems more of a serviceability issue so I've cc'd that mailing
> > list.
> > Also this now relates to the new JEP on finalization removal:
> > https://openjdk.java.net/jeps/421
> > as a tool to help users see where finalizers exist will be useful to
> > that effort.
> > Cheers,
> > David

In general, I think it’s better to have a generic command that can be easily adapted by the user to look for the desired information. We can augment an existing command that already prints out all classes to add the finalization info. It should be pretty easy to grep for “finalizable”, etc, from the output. I would not worry about “too much information being printed”. That can be dealt pretty easily.

For usability, it would be much better than to ask the user to remember many distinct commands for querying related but different information. Also, the VM implementation will be simpler.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6075