Name: clC74495 Date: 01/25/2000

[ Carlos.Lucasius@Canada 2000-01-25: see also "Attachments..." for a more
  complete list of suggested changes from the submitter. ]

Running a VM built from Hotspot 1.0.1 FCS sources on Sparc Solaris 2.7,
we have an ORB test that triggers frequent calls to JVM_StopThread

We have a test case that fails repeatably with this stack

  ---- called from signal handler with signal 10 (SIGBUS) ------
=>[14] Space::prepare_for_compaction(), at 0xfeebe1a8
  [15] MarkSweep::invoke_at_safepoint(0xff1958b8, 0xff23d684, 0xff1afad8,
  [16] VM_Operation::evaluate(0xea30d6e8, 0x17ef80, 0x17ef80, 0xdc, 0xfbb81,
  [17] VMThread::evaluate_operation(0xea30d6e8, 0xea30d6e8, 0x17ef80,

In prepare_for_compaction(), the Space being compacted is
Universe::_new_gen->eden() .
After investigating the contents of eden with dbx,
it appears probable that a thread which was the target of
JVM_StopThread allocated space in eden and then
failed to initialize it, leaving a corrupt region of object memory
with no valid mark or klass words. The next valid object after the
corruption is a COMM_FAILURE object from the ORB, which is often
created just after sending stop() to a thread.

Since sending stop to a thread other than current thread is a safepoint
operation, it would appear that the thread receiving the stop wakes
up from the safepoint, and does not notice the async exception until
after executing Universe::allocate() .

The following sequence might explain what is happening:

The thread which is the target of JVM_StopThread
waits in InterpreterRuntime::at_safepoint at the IRT_END .
If the next bytecode invokes InterpreterRuntime::newarray,
then the pending thread stop exception will be noticed in
Universe::clear_allocate after Universe::allocate executes, when
the call stack would look something like this
  
  InterpreterRuntime::newarray
    oopFactory::new_typeArray
      ...
      typeArrayKlass::allocate
        Universe::clear_allocate
  
The following code change, applied to all similar places in the system
lets our ORB test run corrrectly.
If you want a more complete list of the changes made, please send me e-mail .

--- original code from universe.hpp
  static oop* allocate(int size, TRAPS) {
    debug_only(check_for_valid_allocation_state());
    assert(no_gc_in_progress(), "Allocation during gc not allowed");
    oop* obj = _new_gen->eden()->allocate(size);
    return obj ? obj : Scavenge::invoke_and_allocate(size, false, THREAD);
  }
  
  // Normal allocation (initialized)
  static oop* clear_allocate(int size, TRAPS) {
    oop* obj = allocate(size, CHECK_0);
    return (oop*) memset(obj, 0, size*wordSize);
  }

--- new code
  // Normal allocation (uninitialized)
  static oop* allocate(int size, TRAPS) {
    debug_only(check_for_valid_allocation_state());
    assert(no_gc_in_progress(), "Allocation during gc not allowed");
    if (HAS_PENDING_EXCEPTION) return 0; // Gemstone fix

    oop* obj = _new_gen->eden()->allocate(size);
    return obj ? obj : Scavenge::invoke_and_allocate(size, false, THREAD);
  }

  // Normal allocation (initialized)
  static oop* clear_allocate(int size, TRAPS) {
    oop* obj = allocate(size, THREAD);
    if (obj != NULL) { // Gemstone fix for thread stop
      memset(obj, 0, size*wordSize);
    }
    if (HAS_PENDING_EXCEPTION) return 0; // Gemstone fix
    return obj;
  }

---

A cursory examination of the Hotspot 2.0 Win32 RC1 sources leads me
to believe that the problem may also exist in Hotspot 2.0 .

I would very much like to see a proper solution to this problem
make it into the Hotspot 2.0 FCS sources. I have of course
recommended to our ORB team that they make less use of the
deprecated thread stop , but in the mean time I have to make
JVM_StopThread reliable.


Allen Otis e-mail: ###@###.###
GemStone Systems, Inc. Phone: (503) 533-3603
20575 N.W. von Neumann Drive
Beaverton, OR 97006
(Review ID: 100194)
======================================================================