jtg-i111% /usr/j2se/bin/java -fullversion
java full version "1.3.0"
flag used: -client -Xcomp

VolanoMark client intermitten failuer ( 1/3836)
# HotSpot Virtual Machine Error, Unexpected Signal 4
# Error ID: 4F533F534F4C415249530E435050079A
# Problematic Thread: prio=5 tid=0x8217a10 nid=0x11 runnable
Unexpected Signal 4
occurred at pc=dc097acb

core under /net/jtgb4u4c.eng/export/sail2/core/fcs/jtg-i111.core

Comments from Steve Goldman:

The failure with -client on jtg-i111 that failed with the illegal instruction
is my old "friend" patch_verified_entry (formerly insert_mt_safe). The thread
that failed is now trying to execute in the middle of the jmp instruction
that was patched. When we last left this exciting episode I thought you had
told me that in the client compiler that patch_verified_entry would only
be called as a result of class unloading (make_zombie) and that c1 was safe
otherwise because the other possibility for this kind of patching was
deoptimization which c1 did not do. Looking at it again now it seems like
it is possible to thru the path set_native_function more than once (if I believe
the comments) and if that should happen for method compiled by c1 then this
would explain it. I don't if c1 would compile the same method twice though
but I don't have any other explanation except someone running code for a class
that has been unloaded. That is completely unbelievable so I'm left with the
multiple compilation theory. I'm leaving for today so if you want to look at the
core file have at it. If the multiple compile theory is correct I hope we can
come up with some way around it since as we discussed last time the c2 fix to
align things and have instructions of known to be size of the jmp or larger
as the patchee just didn't seem feasible.


june.zhong@eng 2000-09-01