United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6173783 Tiger server VM seems to be broken
6173783 : Tiger server VM seems to be broken

Details
Type:
Bug
Submit Date:
2004-10-04
Status:
Resolved
Updated Date:
2012-10-09
Project Name:
JDK
Resolved Date:
2005-08-26
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
x86
Priority:
P1
Resolution:
Fixed
Affected Versions:
5.0u1
Fixed Versions:
6

Related Reports
Backport:

Sub Tasks

Description
There is a netbeans.org bug reported at 
http://openide.netbeans.org/issues/show_bug.cgi?id=46993
which basically means that a field that get's assigned in just two places (in constructor and in a method that is never called) suddenly becomes equal to this. 

The constructor looks like:

FilterNode (Node original) {
  this.original = original;
}

and according to java language spec the original can never == this, still in certain situations this happens and is manifested by a StackOverFlow in hashCode 

int hashCode () {
  return original.hashCode();
}

as can be seen in various attachments in the issue. The attachement with most logging is likely this one:

------- Additional Comments From lynggaard 2004-09-23 14:04 PDT -------

Created an attachment (id=17853)
log of patched 21/9 build, another error. zipped

Which should stacktraces of all modifications to the FilterNode.original field and which shows that nobody modifies the field outside of constructor and yet it ends up == this.

I am looking for a help, as I my imagination cannot think of a situation when our code would be broken.
###@###.### 10/4/04 16:52 GMT

                                    

Comments
SUGGESTED FIX

Distinguish virtual and not virtual call to the same method in 
Compile::find_intrinsic().

Webrev:                 http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050817175432.kvn.6173783/workspace/webrevs/webrev-2005.08.17/index.html
                                     
2005-08-18
EVALUATION

Clean up in progress.
###@###.### 2005-06-23 20:54:15 GMT

C2 incorrectly generates dynamic (virtual) call instead of static (direct)
for invokespecial hashCode(), in sources super.hashCode().

The problem in the method Compile::find_intrinsic() which does not
distinguish virtual and not virtual call to hashCode().
                                     
2004-10-04
WORK AROUND

Seems that running client 1.5 VM solves the problem.
###@###.### 10/4/04 16:52 GMT

I would suggest to try the next:
0. Try "-Xint" to run only java interpreter.
   If you still have the problem - it is most likely in your code.
   If the problem does not show up - it may be VM problem, try the next:

1. Exclude the compilation of the method org.openide.nodes.FilterNode.hashCode:
-XX:CompileCommand=exclude,org/openide/nodes/FilterNode,hashCode

2. You can also try to run fastdebug VM:
   replace <java dir>/jre/lib/amd64/server/libjvm.so (save the original) 
   with /home/kvn/VM/amd64/libjvm.so (1.5 09/22 VM)
   or with /net/koori.sfbay/p/jdk12/jdk/1.6.0/ea/b06/binaries/linux-amd64/jre/lib/amd64/server/libjvm.so  (latest 1.6 VM)

Vladimir
###@###.### 10/4/04 20:01 GMT

Thanks Vladimir for your suggestions, I have updated the netbeans.org issue and I'll wait for responses. Ad. #1 - I am not sure we should disable just the hashCode method, maybe we should disable compilation of constructor or the whole FilterNode class.
###@###.### 10/5/04 06:19 GMT
                                     
2004-10-04



Hardware and Software, Engineered to Work Together