Name: skT88420 Date: 12/07/99


java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)


It seems like the JIT compiler thrashes memory on occasions. This has
happened to me on various code samples. This is the smallest code fragment
where this problem occurs (but still rather large, at 1.5MB of JAR file).
If necessary I can attach the JAR for reference.
Now for the description:
    public synchronized void execute( ResourceGrant grant )
                     throws NotReadyException {
      while (isReady()) {
       try {
            MessageInfo message = getMessage(grant, currVRL);
       } catch (InsufficientGrantException ex) {
            System.err.println( "this=" + this );
            Logger.instance().writeDebugMessage(this,
                                   "Insufficient grant for vrl '" + currVRL +
                                   "', remaining grant=" + grant);
            break;
       } catch (LocalFailureException ex) {
            Logger.instance().writeException(this, Logger.WARNING,
                                   "local failure on VRL " + currVRL, ex);
                                   break;
       }
      } /* end while (credit remaining) */
      currVRL = null;
    }

Logger.writeDebugMessage looks like this:
    public synchronized void writeDebugMessage(Object caller,
                                               String content) {
      System.err.println( "caller=" + caller );
      writeMessage(caller, DEBUG, content);
    }

As you can easily see, when InsufficientGrantException is thrown,
this=.... and caller=... should print the same object. This is indeed
what happens if JIT is turned off.
When JIT is turned on, you get the following behavior:
Under JDK1.2.1 (Classic VM (build JDK-1.2.1-A, native threads)):
  this=%MessageRetrieverAgent[]%
  Using log file d:/logs/test.log.12-07
  Using log file d:/logs/err.log.12-07
  java.lang.NullPointerException
          at java.lang.String.valueOf(Compiled Code)
          at java.lang.StringBuffer.append(StringBuffer.java:365)
          at com.vigil.eSense.util.Logger.writeDebugMessage(Logger.java:322)
          .....
Under JDK1.2.2 (Classic VM (build JDK-1.2.2-W, native threads, symcjit)):
  this=%MessageRetrieverAgent[]%
  Using log file d:/logs/test.log.12-07
  Using log file d:/logs/err.log.12-07
  java.lang.InternalError: Illegal object type in getClass
          at java.lang.Object.getClass(Native Method)
          at java.lang.Object.toString(Object.java:201)
          at java.lang.String.valueOf(String.java, Compiled Code)
          at java.lang.StringBuffer.append(StringBuffer.java:365)
          at com.vigil.eSense.util.Logger.writeDebugMessage(Logger.java:322)
          ....
Under JDK1.2.2-001 (Classic VM (build JDK-1.2.2-001, native threads, symcjit)):
  this=%MessageRetrieverAgent[]%
  Using log file d:/logs/test.log.12-07
  Using log file d:/logs/err.log.12-07
  java.lang.InternalError: Illegal object type in getClass
          at java.lang.Object.getClass(Native Method)
          at java.lang.Object.toString(Object.java:201)
          at java.lang.String.valueOf(String.java, Compiled Code)
          at java.lang.StringBuffer.append(StringBuffer.java:365)
          at com.vigil.eSense.util.Logger.writeDebugMessage(Logger.java:322)

Under any of these releases, turning off the JIT compiler
(-Djava.compiler=NONE) removes the problem. This does result in totally
unacceptable performance in my application, however.
(Review ID: 98730)
======================================================================

Name: mc57594 Date: 12/07/99


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

We seem to have discovered a bug in the VM (or maybe the JIT) of
JDK 1.2.2. In irregular intervals (so irregular that we can't reproduce
the bug reliably -- although it happens about once a week) we get the
following internal error from the VM:

[Mon Dec 06 12:06:30 GMT+01:00 1999] (default) : (ilm-s2 ) [(Anfrage-25) ] 4765ms (11870512 /35065848 ):
java.lang.InternalError: Illegal object type in getClass
at java.lang.Object.getClass(Native Method)
at java.lang.Object.toString(Compiled Code)
at java.lang.String.valueOf(Compiled Code)
at de.prodv.ilm.data.ServletRequestData.toString(ServletRequestData.java:250)
at java.lang.String.valueOf(Compiled Code)
at de.prodv.ilm.servlet.RequestServlet.service(RequestServlet.java:195)
at javax.servlet.http.HttpServlet.service(Compiled Code)
at newatlanta.servletexec.ServletThread.run(Compiled Code)

The class 'ServletRequestData' contains the following code around line 250:

    public String toString() {
        String to = "ServletRequestData (ri: " + requestId + ", rt: " +requestType + ", rc: ");

        if (requestContents != null) {
          if (requestContents.toString().length() > 80)
            to += requestContents.toString().substring(0, 80) + "...";
          else
            to += requestContents.toString();
        }
        else
          to += requestContents;

        // ****** THE FOLLOWING LINE IS LINE 250: **************
        to += ", si: " + sessionId + ", cd: " + creationDate + ", cs: " + creationSystem + ", ln: " + loginName + ", lr: " + loginReplacement + ", ak: " + amtskennung + ")";
        return StringUtils.replace(to, "\n", "\\n");
    }

The variables are defined as class variables like this:

    private int requestId;
    private int requestType;
    private Object requestContents;
    private String sessionId;
    private long creationDate;
    private String creationSystem;
    private String loginName;
    private String loginReplacement;
    private String wizardName;
    private String amtskennung;
    private String gruppe;

We are running JDK 1.2.2 on a Windows NT 4.0 server installation
(with SP 4 and option pack installed) under ServletExec from
New Atlanta (http://www.newatlanta.com) together with IIS 4.0.
The server has 256 MB of RAM and a dual processor board with two Pentium
300 Mhz processors installed.

The bug shows up again and again -- as far as we can say that there
does not seem to be a pattern and you can't reproduce it reliably.
(Review ID: 98671)
======================================================================