indy and tailc

Thomas E Enebo tom.enebo at gmail.com
Wed Jan 27 08:10:39 PST 2010


On Wed, Jan 27, 2010 at 3:42 AM, Y. Srinivas Ramakrishna
<Y.S.Ramakrishna at sun.com> wrote:
> Patrick Wright wrote:
> ...
>>
>> Glad to hear that perm gen will eventually go away.
>
> Could you elaborate a little on why it would be nice if the
> perm gen went away? Where would you like its current contents
> (which ones, if any, specifically?) to be located and why?

>From a JRuby and/or general Java perspective having your app throw a
perm gen error is a pain.

In JRuby currently (292 to the rescue) we generate tons of tiny
classes to speed up method invocation or to JIT Ruby methods down to
Java bytecode.  Every class created uses a little bit of perm gem
space (exact details of what is stored in permgen is fuzzy to me --
some dictionary for class names and some internalized form of the
class bytecode??) and with default settings it can be easy to exhaust
permgen with a moderately-sized application.   Because of this we have
to explain what permgen is and how to grow it for people who really
don't want to have to turn an extra knob or any knobs at all.

Removing extra flags and settings is a big win for encouraging use of
the JVM.  The less people typically need to do the better.  For
alternative languages on the JVM we tend to create a lot more classes
than a typical application and generally quite a bit more Objects.
Anything which reduces the amount of non-default tuning people need to
do is a huge win for us.

Stick a stake through the heart of permgen.  I won't miss it :)

-Tom

PS- John, do you know if permgen removal will make it into Java 6 in
an update release?

-- 
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo at gmail.com


More information about the mlvm-dev mailing list