JDK-6458634 : A Klass being allocated may dispatch to the wrong oop_is_parsable
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-08-09
  • Updated: 2010-04-02
  • Resolved: 2006-11-14
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.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
Description
During the allocation of a Klass the vtbl pointer may not be reliable.
See  comments for details

Comments
SUGGESTED FIX Job ID: 20061026145421.jmasa.gc_baseline_vtbl Original workspace: arches:/net/arches/export/home0/java/gc_baseline_vtbl Submitter: jmasa Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061026145421.jmasa.gc_baseline_vtbl/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061026145421.jmasa.gc_baseline_vtbl/workspace/webrevs/webrev-2006.10.26/index.html Fixed 6458634: A Klass being allocated may dispatch to the wrong oop_is_parsable During the allocation of a Klass the vtbl pointer is set in the constructor of Klass and then again in the constructor of each derived Klasses. If the is_parsable() method is consulted before the vtbl pointer has not reached its final value, the wrong oop_is_parsable() may be called. The fix is to reorganize the code so that the setting of the klass pointer can be delayed until after the vtable pointer has been installed. Reviewed by: Ramki and Dave Dice Fix verified (y/n): y Verification testing: The problem was detected as an asertion failure while running a debug build on runThese -plumhall. That test was run repeatedly without the occurrance of the assertion failure. Other testing: runThese -full on a product build, solx86 runThese -quick -testbase_vm -testbase_gc on a product and fastdebug builds, sparc, cms refworkload runs for cms and ps showed no significant differences. Files: update: src/share/vm/gc_interface/collectedHeap.hpp update: src/share/vm/gc_interface/collectedHeap.inline.hpp update: src/share/vm/oops/klass.cpp update: src/share/vm/oops/klass.hpp Examined files: 3884 Contents Summary: 4 update 3880 no action (unchanged)
27-10-2006

EVALUATION See the descritpion of the problem in the comments.
09-08-2006