Using the Hotspot 2.0 Windows sources from
hotspot-2_0-fcs-src-win-01_may_2000.zip

The code in VtableStubs::create_itable_stub in vtableStubs_i486.cpp
is inconsistent with the implementation of start_of_itable() in instanceKlass.hpp.

The implementation of start_of_itable() is
  int* start_of_itable() const        { return start_of_vtable() + align_object_offset(vtable_length()); }

The implementation of create_itable_stub needs something like this change.
==================
cvs diff -r1.2 vtableStubs_i486.cpp
146,147c146,151
<   assert(vtableEntry::size() * wordSize == 4, "adjust the scaling in the code below");
<   __ movl(edx, Address(ebx, instanceKlass::vtable_length_offset() * wordSize)); // Get length of vtable
---
>   __ movl(edx, Address(ebx, instanceKlass::vtable_length_offset() * wordSize)); // Get length of vtable (Gemstone, in words)
>   // Gemstone fix for alignment, to go with the code in instanceKlass.hpp , see sparc interp.
>   if (align_object_offset(1) > 1) {  // Gemstone, 
>     __ round_to(edx, align_object_offset(1));  // add 2 instructions at 6 bytes each
>   }
>   assert(vtableEntry::size() * wordSize == 4, "adjust the scaling in the leal code below");
252,253c256,257
<     COMPILER1_ONLY(return (DebugVtables ? 300 : 61) + (CountCompiledCalls ? 6 : 0); )
<     COMPILER2_ONLY(return (DebugVtables ? 300 : 56) + (CountCompiledCalls ? 6 : 0);  )
---
>     COMPILER1_ONLY(return (DebugVtables ? 300 : (61 + 12) ) + (CountCompiledCalls ? 6 : 0); )
>     COMPILER2_ONLY(return (DebugVtables ? 300 : (56 + 12/*Gemstone alignment fix*/)) + (CountCompiledCalls ? 6 : 0);  )
==================

On Windows, this inconsistency only causes problems if the size of oopDesc is changed

Also, on Windows,  in templateTable_i486.cpp, 
TemplateTable::fast_invokeinterface is missing the alignment code, like this:
=====
1974c2260,2265
<   __ movl(esi, Address(edx, instanceKlass::vtable_length_offset() * wordSize)); // Get length
 of vtable
---
>   __ movl(esi, Address(edx, instanceKlass::vtable_length_offset() * wordSize)); // Get length
 of vtable in words
> 
>   // Gemstone fix for alignment, to go with the code in instanceKlass.hpp , see sparc interp.
>   if (align_object_offset(1) > 1) {
>     __ round_to(esi, align_object_offset(1));
>   }
====


On Solaris, a similar problem exists, I believe in the 
hotsparc-2_0-pre-fcs-b-src-sol-03_may_2000.zip  sources.

The implementation in cpu/sparc/vm/vtableStubs_sparc.cpp appears to
attempt to round after multiplying by  (vtableEntry::size() * wordSize),
and I don't think this rounding is working .  
Since the and3 to "isolate the odd bit" is done after the sll, I think
the and3 will always have a zero result. I changed the  sparc code
to use the round_to() from the assembler and some of the SEGV problems I
was having went away.  The instruction count in create_itable_stub is unchanged
after this fix


========
diff -r1.3 vtableStubs_sparc.cpp
153d152
<   __ ld(Address(RklassOop, 0, instanceKlass::vtable_length_offset() * wordSize), Rscratch);
155,165c154,178
<   // %%% Could store the aligned, prescaled offset in the klassoop.
<   __ sll(Rscratch, exact_log2(vtableEntry::size() * wordSize), Rscratch);
<   // see code for instanceKlass::start_of_itable!
<   const int vtable_alignment = align_object_offset(1);
<   assert(vtable_alignment == 1 || vtable_alignment == 2, "");
<   const int odd_bit = vtableEntry::size() * wordSize;
<   if (vtable_alignment == 2)
<     __ and3(Rscratch, odd_bit, Rtemp);  // isolate the odd bit
<   __ add(RklassOop, Rscratch, Rscratch);
<   if (vtable_alignment == 2)
<     __ add(Rscratch, Rtemp, Rscratch);  // double the odd bit, to align up
---
> // OLD JAVASOFT CODE , I think this alignment code is bad.
> //  __ ld(Address(RklassOop, 0, instanceKlass::vtable_length_offset() * wordSize), Rscratch);
> //
> //  // %%% Could store the aligned, prescaled offset in the klassoop.
> //  __ sll(Rscratch, exact_log2(vtableEntry::size() * wordSize), Rscratch);
> //  // see code for instanceKlass::start_of_itable!
> //  const int vtable_alignment = align_object_offset(1);
> //  assert(vtable_alignment == 1 || vtable_alignment == 2, "");
> //  const int odd_bit = vtableEntry::size() * wordSize;
> //  if (vtable_alignment == 2)
> //    __ and3(Rscratch, odd_bit, Rtemp);  // isolate the odd bit
> //  __ add(RklassOop, Rscratch, Rscratch);
> //  if (vtable_alignment == 2)
> //    __ add(Rscratch, Rtemp, Rscratch);  // double the odd bit, to align up
> // END OLD CODE
>
> // GEMSTONE, use this alignment code to agree with code in fast_invokeinterface
>   __ ld(Address(RklassOop, 0, instanceKlass::vtable_length_offset() * wordSize), Rscratch);  // load vtable length in words into Rscratch
>   if (align_object_offset(1) > 1) {
>     __ round_to(Rscratch, align_object_offset(1));
>   }
>   __ sll(Rscratch, exact_log2(vtableEntry::size() * wordSize), Rscratch); // convert to byte offset
>   __ add(RklassOop, Rscratch, Rscratch);
>
> // END GEMSTONE fix

-----------------------------------------------------------------------------

Other licensees probably won't see the bug unless they
do something to disturb alignment of things in instanceKlass.hpp

It is a fairly difficult bug to diagnose, at least
on Sparc, because the SEGV's produced appear to be outside of any
intepreter or C2 generated code, and cause a direct core dump,
since the hotspot SEGV handler can't run successfully for some reason.

On NT, I had to enhance the printing logic
in hotspot's unexpected exception handler to have it tell me what kind
of stub the fault was occurring in.