Name: dk106046 Date: 04/08/2002

1. Basic Info:
Platform (Solaris/Win32):
Solaris

Operating System Level/Version:
5.8

Specific Sun Release Information:
1.2.2_11

2. Workarounds:
Increase "-Xmaxjitcodesize", but this is not a complete workaround as similar
corruption could still occur if the application dynamically loads more classes.

3. Test Case and Failure Data:

JIT CORRUPTION:
Original problem report
-----------------------
Customer has standard java classes (not EJBs) that get called by sessionBeans.
Occasionally something very strange happens where the wrong class's method is
called. This is not easily reproducible, but when it does happen it stays in
error until the appserver is restarted.

Here is a snippet of code to illustrate the problem:

//===begin code of abstract parent and 2 subclasses=====

public abstract class ParentP
{
private transient Connection conn = null;
private transient PreparedStatement ps = null;
private transient ResultSet rs = null;

protected abstract String selectSQL();

public void retrieve()
{
rs = null;
ps = null;

conn = super.getConnection(CRGroupColl);

String sql = selectSQL();

// The above _sometimes_ goes to ChildA.selectSQL(),
// even if the current instance is actually ChildB
// ..... lots of other stuff
}
}

public class ChildA extends ParentP
{
private transient Connection conn = null;
private transient PreparedStatement ps = null;
private transient ResultSet rs = null;

protected String selectSQL()
{
return("String from ChildA");
}
}

public class ChildB extends ParentP
{
protected String selectSQL()
{
return("String from ChildB");
}
}

//======end code=====

When the ParentP.retrieve() method is called on an instance of ChildB,
sometimes the ChildA.selectSQL() method is called from the retrieve()
instead of the expected ChildB.selectSQL.

We suspect this might be a JIT problem, because when it does happen it
stays in error until the appserver is restarted, and if the corruption
hasn't happened after a certain time then it won't occur.

We suggested removing the duplicate attributes in the child class and
at first it looked like this had resolved the problem - but the error
occurred again a few weeks later.

The error always seems to occur the first time a function is executed
on a certain page (that invokes a StatefulSessionBean that calls the
class that then picks up the wrong method).

Recent update
-------------

Problem is more reproducible when we reduce the maximum amount allowed
for JIT'd code (-Xmaxjitcodesize). After we see the JIT error message:
"Ran out of space for compiled code", the corruption occurs.

The customer's view is that the JVM should never corrupt the behaviour
of application code, even when it runs out of space for compiled code.

This problem has never occurred with the JIT, or just method inlining
disabled. Similarly, it has not occurred with more space available for
JIT'd code.


======================================================================