JDK-4642821 : Keep interned strings out of perm gen
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: generic
  • Submitted: 2002-02-25
  • Updated: 2019-01-15
  • Resolved: 2011-04-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
We've been seeing increased customer failures due to running out
of perm gen.  At one time the char[] data of strings was not kept
in perm gen, but now it is:

> Looking at StringTable::basic_add(), you'll see that if a
> string to be interned is not in the old-gen, a copy is
> made in the perm generation:
>  string = java_lang_String::create_tenured_from_unicode(name, len, CHECK_0);
> which puts both the String and the char[] in perm. I do
> remember looking at the code once, however, when it only put
> the String object in perm (avoiding the array copy) but
> that no longer appears to be the case.

Since the perm gen sizing uses a different sizing policy than old
gen, and in particular is more strictly bounded in size, applications
which intern strings heavily are penalized.  Its seems wise to keep 
objects not sematically required to be in perm gen from being placed

(There might be interactions with CMS and a shared gen when that is 

EVALUATION I think we should address the interned strings problem first, and see what that does to the perm gen usage. The other suggestions sound reasonable, but involve more work for potentially less payoff. ###@###.### 2002-08-07