JDK-6173783 : Tiger server VM seems to be broken
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u1
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: x86
  • Submitted: 2004-10-04
  • Updated: 2012-10-09
  • Resolved: 2005-08-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u6Fixed 6 b49Fixed
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
18-08-2005

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
04-10-2004

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().
04-10-2004