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.
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.