Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
This fixes the finalization implementation to invoke the finalize method
via shared secret so that it will call the same method as the bytecode
invocation.
The current implementation uses JNI_GetMethodID to find the finalize
method of a given instance. JNI_GetMethodID returns the private finalize
method which gets invoked during finalization (which is different than
the method looked up via invokevirtual). If there is a static method
matching the name and descriptor, it will throw NoSuchMethodError even
if the base class has a matching instance method. JDK-8027270 is filed
for this JNI_GetMethodID issue.
This change replaces the JNI call to the finalize method with the shared
secret as Jeroen suggests [1]. This will resolve this bug independent
of JDK-8027270 and also avoid the overhead of the JNI calls.
The behavioral change with this fix should rarely impact any existing
application. It would only impact code that defines a finalize method
in a base class and also a private finalize method in a subclass. The
only way to have a private finalize method is to write to the bytecode
directly.
thanks
Mandy
P.S. I would love to use Martin's beloved GcFinalization utility that we
can extend our testlibrary in the future. The new regression test is
simple enough that a counter would do its work.
[1]
http://weblog.ikvm.net/PermaLink.aspx?guid=87432f77-7e58-4f37-9f6d-d5bac453c7d6
[2] https://bugs.openjdk.java.net/browse/JDK-8027351
