xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cos...@eng.sun.com
Subject Re: HotSpot Bashing (was RE: [spinnaker] Announce)
Date Mon, 10 Jul 2000 22:55:24 GMT
> How do you know when you're building a next gen parser?  Wasn't Xerces a
> next gen parser at some point?
> If Sun releases a new VM while Spinnaker is still being developed, will you
> go back and change the way it was written?

You are right, HotSpot is not the last or only VM, and we want to be able
to optimize for JDK1.1, HotSpot, or any other VM - or not optimize at
all. This is not possible in xerces, which has JDK1.1 optimizations and
nothing else.

Having HotSpot detect JDK1.1 optimizations is not a solution, we need to
use JDK1.1 optimizations in JDK1.1 and normal ( unoptimized ) code in
HotSpot ( or even Hot-Spot optimized code for hotspot and jit optimized
code when a JIT is used ). 

This will also help a lot with the code clarity: 
  try {
    fgTempBuffer[outOffset] = (char)ch;
  } catch (NullPointerException ex) {
    fgTempBuffer = new char[CHUNK_SIZE];
    fgTempBuffer[outOffset++] = (char)ch;
  } catch (ArrayIndexOutOfBoundsException ex) {
     char[] newBuffer = new char[outOffset * 2];
     System.arraycopy(fgTempBuffer, 0, newBuffer, 0, outOffset);
     fgTempBuffer = newBuffer;
     fgTempBuffer[outOffset++] = (char)ch;

Is equivalent with:
  if( fgTempBuffer == null ) 
       fgTempBuffer = new char[CHUNK_SIZE];
  if( outOffset == fgTempBuffer.length ) 
  fgTempBuffer[ outOffset ++ ] = ch;

The first piece can't be optimized by hotspot ( AFAIK ). It is a great
optimization for JDK1.1, and it should be used in 1.1 VMs.

This kind of code is used all over xerces, in all classes. I don't think
it's bad code, but you don't have to pay the price of 1.1 optimizations in
1.3 VMs ( even if HotSpot could detect it's 1.1).


View raw message