Users report (and we have verified) that running
our document indexing program under Windows NT 4.0
with the JIT compiler supplied with JDK1.1.6 produces
the following error message for relatively small text
collections (10 MB or so of HTML) :

*** panic: 16-bit string hash table overflow

abnormal program termination

Would appreciate info regarding the source and
possible resolution of this problem, which 
appears to be new under 1.1.6 .
(Review ID: 29559)
======================================================================

We are recommending that our customers use
Microsoft's JVM until this problem is resolved.



EDITOR's NOTE: you could also run the 1.1.6 JVM with
the JIT turned off by using:

   java -nojit  [other flags...]  <class name>
or
   jre -nojit [other flags...]  <class name>

Refer to this URL for the Windows version of the Tools Reference Pages:

http://www.javasoft.com/products/jdk/1.1/docs/tooldocs/win32/java.html


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

The workarounds are: load less classes or upgrade to JDK 1.2.x.


  xxxxx@xxxxx   1999-06-02

This bug will be forwarded to Symantec for further investigation.

  xxxxx@xxxxx   1998-05-04

This bug was reproducible without the JIT (See the message below from the user)
Since it is not clear what is causing the bug, I am re-assigning the bug to
"other" sub-category.


Date: Tue, 12 May 1998 14:11:50 -0700 (PDT)

Subject: Re: BugID 4134584 (opaque error message: *** panic: 16-bit string hash table overflow)

MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-MD5: oIpDasoFYYdMRUEIaMZesA==

FYI:  Looks like this bug (eBugID 4134584) may not
be against the JIT.

Note, however, that he was unable to run the
symcjit_g.dll because it wanted "MSVCRTD.DLL"

Tim x53241
------------- Begin Forwarded Message -------------

Date: Tue, 12 May 1998 16:44:27 -0400

MIME-Version: 1.0

Subject: Re: BugID 4134584 (opaque error message: *** panic: 16-bit string 
hash table overflow)
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by earth.sun.com id 
NAA06226

Hi Tim,

I just reproduced the bug in Sun-JVM-modulo-JIT (-nojit).  I infer that the 
problem is
Sun's and not Symantec's.

JDK1.1.5K/green-threads/nojit on Ultrasparc doesn't have this problem.
Nor does 1.2beta3 on Ultrasparc.  I will try the latest WinNT 1.2 beta 
tomorrow morning
and let you know if it is also bug-free.

I was also able to reproduce the bug under the new symcjit.dll you 
supplied.  I was not
able to use symcjit_g.dll; it wants "MSVCRTD.DLL", which doesn't seem to be 
on our NT 4
Server box, and I suspect it wouldn't shed any light on this particular 
bug.

I would be happy to supply a .jar file containing our product and an 
example document
collection which will tickle the bug.  The total size of that test package 
would be on the
order of 5 MB.  Please let me know if you'd like that as an email 
attachment or if I
should point you at an ftp site.

Please note that even for a document collection of only 10 MB, it is 
perfectly normal for
our program to create 150 000 Strings, as we require a String for every 
unique word.  

Our software is actually designed for terabyte-sized document collections, 
and the number
of Strings grows linearly with the size of the document collection in the 
worst case
(mostly due to misspelled words).  If there is an intentional hard limit on 
the number of
String objects we can allocate in your 1.1 JVM, could you please tell us 
about it so that
we can code around it?  We hate to have to refer people to Microsoft's JVM, 
and will go to
almost any length to accomodate your JVM's idiosyncrasies.

is all.

Timothy Bell wrote:
> 
> Hello Mike
> 
> I've been asked to pass this new drop of the JIT
> compiler to you.
> 
> If you could spend some time running your test scenario
> using this new JIT, I'd appreciate it.  This JIT is not
> ready to go out to the world at large... as I understand
> it, it's just the results of the weekly build, so please
> don't pass it on to anyone.
> 
> please unzip the attached file to get the symcjit.dll and
> symcjit_g.dll files.
> 
> To test with the new jit, just replace the current symcjit.dll in
> the 1.1.6 bin dir with the new one.  I suggest that you save the
> old files first by renaming them (EG:  to symcjit.dll_01 and
> symcjit_g.dll_01).  Then run the app as usual.  I am also
> attaching a symcjit_g.dll to get more debugging info.
> 
> ------------- Begin Forwarded Message -------------
> 
> Date: Fri, 8 May 1998 13:05:32 -0700 (PDT)
> From: Deepa Viswanathan <  xxxxx@xxxxx  >
> Subject: pass the new symcjit.dll to your customers
> To:   xxxxx@xxxxx  ,   xxxxx@xxxxx  ,   xxxxx@xxxxx  ,
>   xxxxx@xxxxx  
> Cc:   xxxxx@xxxxx  
> MIME-Version: 1.0
> 
> Hi all,
> 
> We are actively investigating the 1.1.6 Symantec JIT bugs.  The
> following
> bugs submitted by you don't have information to be reproduced.
> But we do
> have a new drop of the Symantec JIT that could potentially fix the
> problems.
> 
> bugid   synopsis
>         submitter
> 4135304 Retreiving Float/Double data thru JDBC-ODBC bridge causes
> an error (ellis)
> 4134584 opaque error message: *** panic: 16-bit string hash table
> overflow (tbell)
> 4134585 getThreadContext failed (errcode: 57) jre116 hard crash
>         (tbell)
> 4122416 internal JIT (3.00.030(x)) error 'Unuse64' has occured
>         (sandhya)
> 4133602 1.1.6 jit crashes when reading double from ResultSet
>         (dalem)
> 4133712 Internal JIT error in 1.1.6 ('StackFPU: FPU0')
>         (dalem)
> 
> Can you please pass the attached symcjit.dll to your customers and
> ask them
> to verify if their bugs have been fixed?  This input would be
> critical
> in deciding if the new drop is good enough to be put out as a
> patch on the Web.
> So, can you please try to get this info by Monday?
> 
> To test with the new jit, just replace the current symcjit.dll in
> the 1.1.6 bin
> dir with the new one and run the app. as usual.  I am also
> attaching a symcjit_g.dll
> to get more debugging info.
> 
> Thanks for all your efforts,
> Deepa
> (Responsible engineer for Symantec JIT bugs)
> 
> p.s please unzip the attached file to get the symcjit.dll and
> symcjit_g.dll
> 
> ------------- End Forwarded Message -------------
> 
>   Tim Bell      xxxxx@xxxxx           Source Integration
> Engineering
>   Java Software Division of Sun Microsystems, Inc.
> 
>     "JavaSoft(TM), Java(TM), and Java(TM) Development Kit
>     are all trademarks of Sun Microsystems, Inc."
>     "JavaSoft(TM), Java(TM), et Java(TM) Development Kit
>     sont des marques d�épos�ées ou enregistr�ées de Sun
>     Microsystems, Inc. aux Etats-Unis et dans d'autres pays."
> 
>                                                   
---------------------------------------------------------------------------
---------------
> 
>                          Name: x116b043.zip
>    x116b043.zip          Type: Zip Compressed Data 
(application/x-zip-compressed)
>                      Encoding: BASE64
>                   Description: x116b043.zip

------------- End Forwarded Message -------------


  Tim Bell      xxxxx@xxxxx           Source Integration Engineering
  Java Software Division of Sun Microsystems, Inc.

    "JavaSoft(TM), Java(TM), and Java(TM) Development Kit
    are all trademarks of Sun Microsystems, Inc."
    "JavaSoft(TM), Java(TM), et Java(TM) Development Kit
    sont des marques d�épos�ées ou enregistr�ées de Sun
    Microsystems, Inc. aux Etats-Unis et dans d'autres pays."

  xxxxx@xxxxx   1998-05-19

I located the problem with the miracle of grep technology.
Check out src/share/java/util/util.c, line 276.  Happily, this
message does not still appear anywhere in the 1.2 sources.

  xxxxx@xxxxx   1998-05-19

See the comment section for feasibility/risk assessment.

  xxxxx@xxxxx   1998-06-03

-------------------------------------------------------

The following code still gives the error on 1.1.7l

class Bug
{
  public static void main(String[] args)
    {
      int i=0;
      String x;
      while (true) 
	{
	  x=(""+i).intern();
	  System.out.println(i);
	  i++;
	}
    }
}

Output :
...
...
26760
26761
26762

*** panic: 16-bit string hash table overflow
SIGABRT   6*   abort (generated by abort(3) routine)
    si_signo [6]: SIGABRT   6*   abort (generated by abort(3) routine)
    si_errno [0]: Error 0
    si_code [-1]: SI_LWP [pid: 23632, uid: 56526]
        stackbase=EFFFE138, stackpointer=EFFFDE78

Full thread dump:
    "Finalizer thread" (TID:0xee300210, sys_thread_t:0xef371db8, state:R) prio=1
    "Async Garbage Collector" (TID:0xee300258, sys_thread_t:0xef471db8, state:R) prio=1
    "Idle thread" (TID:0xee3002a0, sys_thread_t:0xef541db8, state:R) prio=0
    "Clock" (TID:0xee300088, sys_thread_t:0xef571db8, state:CW) prio=12
    "main" (TID:0xee3000b0, sys_thread_t:0x6dc90, state:R) prio=5 *current thread*
        Bug.main(Bug.java:9)
Monitor Cache Dump:
Registered Monitor Dump:
    Thread queue lock: <unowned>
    Name and type hash table lock: <unowned>
    String intern lock: owner "main" (0x6dc90, 1 entry)
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
    Dynamic loading lock: <unowned>
    Monitor IO lock: <unowned>
    Child death monitor: <unowned>
    Event monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
        Waiting to be notified:
            "Clock" (0xef571db8)
    Sbrk lock: <unowned>
    Monitor registry: owner "main" (0x6dc90, 1 entry)
Thread Alarm Q:
Abort (core dumped)


  xxxxx@xxxxx   1998-09-22

We now allow Java programs to create as many interned strings as
they want. However, other literals such as class name, method
name, and method signature are still subject to the 30K limitation.

  xxxxx@xxxxx   1999-06-02

I'm seeing the same problem with Solaris 2.5.1 and JDK1.1.6,
so it's not just a JIT problem.  My code runs just fine on
JDK1.1.5.
Mike  :)

The bug can be reproduced cwith the following  very
simple program:
 class Bug{
   public static void main(String[] args){
     int i=0;
     String x;
     while (true) {
       x=(""+i).intern();
       System.out.println(i);
       i++;
     }
   }
 }

 

This bug is still present in 1.1.7, so why is it marked closed?

The bug is present in JDK 1.1.7A too.

This bug is NOT FIXED until a version of 1.1 is released that handles intern()
correctly !

"640K ought to be enough for anybody." 
  - Bill Gates
"32,000 String instances ought to be enough for anybody."
  - SUN

The bug is present in JDK 1.1.7B too.

We have the same problem also.  Please read on:
Configuration:
1) Solaris 2.6, E450 with 1 Gig RAM
2) IBM WebSphere Application Server
3) Sun JVM 1.1.6 with green thread
Test:
1) We employed our test software to spawned out 20 users. each with 10
iterations.  The test consists of running some text search and viewing the
search results.  The program is a servlet running on IBM's WebSphere
Application Server.
After running the test for about the 7th iteration, the JVM crashed and this
message on the console:
*** panic: 16-bit string hash table overflow
Nothing else useful can be found on any log files.
If this is a problem with the JVM, please advise on a resolution.
Thank you.
Mike Liu (mike@careerpath.com)

It gets even better -- since all string literals
are automatically interned, any string literals used
add to the count toward intern() panic.

Download the sockperf package from the IBM 
Alphaworks site. Inside that zip you will find 
IBMJDK117.zip. Grab it, and use it. It fixes this
problem and significantly improves the performance
of everything else!

This bug has been fixed in IBM's Java for AIX
and Windows 95/98/NT.  It's not a complete fix,
as it only doubles the no. of possible ID values.
The above test program on AIX would get to
50784.  This seems to be sufficient to fix most of
the problems our customers have had.  String
interning, however, should be completely
re-implemented as in Java 1.2.

I should mention we also get rid of the nasty
panic message, throwing a  OutOfMemoryError
exception.

This bug is still present in 1.1.8, so why is it marked closed?

Wenn you try to create 6709 classes with 
Class.forName(...);
you get the error with JDK1.1.7 and JDK1.1.8.
With JDK1.1.5 and the IBMJDK 
there is no problem.
cu KDJ

We can reproduce this problem with JDK 1.1.6, 1.1.7 in 
all its flavors and 1.1.8.
The bug report indicates this is fixed for JDK 1.1.7 
and 1.1.8. Why 2 "fixed in" versions ? How come it is both 
reported against 1.1.7 and fixed in 1.1.7 ?
This bug cannot be marked "closed" when it 
is not difficult to reproduce on JDK 1.1.8, the 
shipping version for NT.
Is there any hope of having this bug re-opened for
the JDK 1.1.x series ?
We can attempt a work around for this problems if:
a) a clear explanation on how to proceed is provided
(or else, we have to spend time figuring that out
with no help from a bug report marked closed)
b) a timeframe, even vague, is provided for a JDK 1.1.x
fix for it.
Otherwise and in the meantime, we do not have any
reasonable choice but give our customers the 
choice of running our applications:
- on the Microsoft VM for 1.1.x products
- on JDK 1.2.x once they decide to migrate there.
It is obvious from the comments in this bug report
that we are not the only ones in that situation.
Getting this fixed will help the whole Java community
and, bottom line, Sun.