is PermGen lurking heavily in Scala ?

I've used Scala since 2007, hasn't been a headache for me yet.

On Tue, Nov 23, 2010 at 11:00 PM, Live Nono <livenono [at] gmail [dot] com> wrote:

hi

when speaking of Scala with some co workers, one of them expressed his
fear that scala would have perm gen issue, due to the number of
generated classes for each scala construct.

When searching for more info on it, I saw issue like this with Lift,
but they looked like more linked to bad use of it (like a web
container not cleaning the perm gen properly). Yet I didn't find a
more extensive answer to it.

could someone enlighten me ?

thanks in advance

best
nono

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

>>>>> "Live" == Live Nono writes:

Live> hi when speaking of Scala with some co workers, one of them
Live> expressed his fear that scala would have perm gen issue, due to
Live> the number of generated classes for each scala construct.

Live> When searching for more info on it, I saw issue like this with
Live> Lift, but they looked like more linked to bad use of it (like a
Live> web container not cleaning the perm gen properly). Yet I didn't
Live> find a more extensive answer to it.

Live> could someone enlighten me ?

It sounds like your coworker has the misconception that Scala makes new
classes at runtime. It doesn't. Classes are created at compile time.

On 2010, Nov 23, at 11:00 PM, Live Nono wrote:
> when speaking of Scala with some co workers, one of them expressed his
> fear that scala would have perm gen issue, due to the number of
> generated classes for each scala construct.

It depends on what you mean by "perm gen issue"? You can expect to have to increase the default permgen size, but is this an issue? The same thing has happened to my java-based applications the last five years.

Otherwise, I haven't seen anything that I would describe as an issue. At least not yet.

yours
Geir

On Wed, Nov 24, 2010 at 9:00 AM, Live Nono wrote:
> when speaking of Scala with some co workers, one of them expressed his
> fear that scala would have perm gen issue, due to the number of
> generated classes for each scala construct.
>
> When searching for more info on it, I saw issue like this with Lift,
> but they looked like more linked to bad use of it (like a web
> container not cleaning the perm gen properly). Yet I didn't find a
> more extensive answer to it.
>
> could someone enlighten me ?

Lets be clear about what the misnamed "Perm Gen" actually is. Its not
a generation of the heap that ever stores Objects. Its the region of
memory where the JVM stored loaded classfile data. It has a default
size and if you load more classes at once than fit, you get an
OutOfMemoryError.

Scala does generate more classfile data per line of source code, but
requires fewer lines of source code. Therefore, you may (or may not)
need a bigger perm gen than for an "equivalent" Java app. I assume you
know how to set this on your JVM.

AFAIK, the most common way that perm gen memory errors manifest is in
"reloading class-loader contexts" (Tomcat is on such example), where
some code, outside the reloading-context, holds onto / caches a ref to
something from within it, making it noncollectable on expiration.
Expired context's classfiles cannot be cleaned if there are any
remaining instances of any class from them. So many copies of your app
accumulate in the perm gen until they overflow it.

Apparently, and in accordance with my experience, many common Java
libraries can cause such problems. Ive found its easier to set the
perm size huge (eg 2Gb) during dev, when the reloading is frequent,
than to try to find and eliminate the leaky libraries from your
project.

-Ben

When working with JRebel this can become an issue, but its easily resolved by increasing the default PermGen size. I use JRebel for Lift development, it reloads classes off disk into memory on the fly to save you having to restart your web container.
I use this JVM argument: -XX:MaxPermSize=384m and have not had any problems.
- Alex
On Tue, Nov 23, 2010 at 5:00 PM, Live Nono <livenono [at] gmail [dot] com> wrote:

hi

when speaking of Scala with some co workers, one of them expressed his
fear that scala would have perm gen issue, due to the number of
generated classes for each scala construct.

When searching for more info on it, I saw issue like this with Lift,
but they looked like more linked to bad use of it (like a web
container not cleaning the perm gen properly). Yet I didn't find a
more extensive answer to it.

could someone enlighten me ?

thanks in advance

best
nono

On Tue, Nov 23, 2010 at 2:00 PM, Live Nono <livenono [at] gmail [dot] com> wrote:

hi

when speaking of Scala with some co workers, one of them expressed his
fear that scala would have perm gen issue, due to the number of
generated classes for each scala construct.

When searching for more info on it, I saw issue like this with Lift,
but they looked like more linked to bad use of it (like a web
container not cleaning the perm gen properly). Yet I didn't find a
more extensive answer to it.

In the case of Lift and PermGen, it's a potential issue at development time, but not in production.  Why?  Because as you develop and your classes get reloaded into the container, if the old ones are not removed, then you run out of PermGen space. 

I have the following flags in my sbt file and have not run out of PermGen space:
java -Xmx1512M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m
 
In terms of the number of classes Scala produces... it actually not many more than you'd see in a similarly complex Java application.  In my apps, I see a 8x reduction in lines of code vs. similar Java apps that I've written.  On the other hand, I see a similar number of class files.  What this tells me is that much of the boilerplate that I find in my Java applications is handled by the compiler rather than the editor.

could someone enlighten me ?

thanks in advance

best
nono

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

Thanks all for your answers :)

it cleared the matter I think, with more convincing speech hopefully ;)

thanks again
best

2010/11/24 David Pollak :
>
>
> On Tue, Nov 23, 2010 at 2:00 PM, Live Nono wrote:
>>
>> hi
>>
>> when speaking of Scala with some co workers, one of them expressed his
>> fear that scala would have perm gen issue, due to the number of
>> generated classes for each scala construct.
>>
>> When searching for more info on it, I saw issue like this with Lift,
>> but they looked like more linked to bad use of it (like a web
>> container not cleaning the perm gen properly). Yet I didn't find a
>> more extensive answer to it.
>
> In the case of Lift and PermGen, it's a potential issue at development time,
> but not in production.  Why?  Because as you develop and your classes get
> reloaded into the container, if the old ones are not removed, then you run
> out of PermGen space.
>
> I have the following flags in my sbt file and have not run out of PermGen
> space:
> java -Xmx1512M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m
>
> In terms of the number of classes Scala produces... it actually not many
> more than you'd see in a similarly complex Java application.  In my apps, I
> see a 8x reduction in lines of code vs. similar Java apps that I've
> written.  On the other hand, I see a similar number of class files.  What
> this tells me is that much of the boilerplate that I find in my Java
> applications is handled by the compiler rather than the editor.
>
>>
>> could someone enlighten me ?
>>
>> thanks in advance
>>
>> best
>> nono
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
> Surf the harmonics
>

Useful to know, thanks everybody for the contributions
Fernando

On 26 November 2010 11:45, Live Nono <livenono [at] gmail [dot] com> wrote:

Thanks all for your answers :)

it cleared the matter I think, with more convincing speech hopefully ;)

thanks again
best


2010/11/24 David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com>:
>
>
> On Tue, Nov 23, 2010 at 2:00 PM, Live Nono <livenono [at] gmail [dot] com> wrote:
>>
>> hi
>>
>> when speaking of Scala with some co workers, one of them expressed his
>> fear that scala would have perm gen issue, due to the number of
>> generated classes for each scala construct.
>>
>> When searching for more info on it, I saw issue like this with Lift,
>> but they looked like more linked to bad use of it (like a web
>> container not cleaning the perm gen properly). Yet I didn't find a
>> more extensive answer to it.
>
> In the case of Lift and PermGen, it's a potential issue at development time,
> but not in production.  Why?  Because as you develop and your classes get
> reloaded into the container, if the old ones are not removed, then you run
> out of PermGen space.
>
> I have the following flags in my sbt file and have not run out of PermGen
> space:
> java -Xmx1512M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m
>
> In terms of the number of classes Scala produces... it actually not many
> more than you'd see in a similarly complex Java application.  In my apps, I
> see a 8x reduction in lines of code vs. similar Java apps that I've
> written.  On the other hand, I see a similar number of class files.  What
> this tells me is that much of the boilerplate that I find in my Java
> applications is handled by the compiler rather than the editor.
>
>>
>> could someone enlighten me ?
>>
>> thanks in advance
>>
>> best
>> nono
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
> Surf the harmonics
>