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.

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