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)
                                     

EVALUATION

See the descritpion of the problem in the comments.