JDK-6494989 : Breakpoints in empty finalizer methods treated incorrectly
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0u9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-17
  • Updated: 2023-12-13
  • Resolved: 2013-09-12
Related Reports
Relates :  
JDK-4248826 - Method entry/exit events are not created for empty methods in Hotspot VM
Relates :  
JDK-6244003 - JVM(server) freezes with -Xcomp -XX:CompileOnly=freeze.loop and -XX:-Inline in 6.0b27
Relates :  
JDK-4990749 - GetBytecodes returns breakpoint bytecodes instead of real bytecodes
Relates :  
JDK-4289162 - Application is running to completion for a break point in Empty Method
Description
Hi,                                                                        
                                                                           
there is a problem when a breakpoint is set in an empty finalize()         
method. Consider the following situation:                                  
                                                                           
Class A has an empty finalize() method, so it would not take part in the   
 finalizing game (no Finalizer refs allocated for objects of that class)   
. Now a user sets a breakpoint in the finalize() method and after that     
we load Class B, which has Class A as its superklass. Class B does not     
overrides finalize(), so we would expect objects of Class B not to take    
part in the finalizer game too.                                            
                                                                           
But in ClassFileParser::set_precomputed_flags(), where it is detected if   
 a class has a non-empty finalize() method, methodOopDesc::                
is_empty_method() is called, which just checks the first bytecode of the   
 method. But now we have the breakpoint bytecode at this place, so         
methodOopDesc::is_empty_method() thinks the method is not empty and        
objects of Class B are treated as having a non-empty finalize method.
Comments
I'm closing this issue as "Won't Fix". In fact, we do not have resources to investigate the problems like this. This problem is old and does not look important. There is a good workaround: avoid setting breakpoints to the empty finalizers.
12-09-2013
EVALUATION I agree that this seems to be a real bug as there is an inconsistency in how empty finalize methods of classes A and B are treated. But it is not clear yet how it'd be better to fix. For instance, do we really want to hit a breakpoint which set in an empty finalize method? If the answer is "Yes" then the finalizers of both classes A and B need to take a part of the finalizer game. If the answer is "No" then, probably, it can be fixed easier. We need to investigate it more. I feel that maybe this corner case does not really hit much users, so maybe the priority of the bug can be lowered to p4.
11-07-2007