1

I have an application in Play Framework v2.3.7 written on Scala v2.11.4. It is running on a server and once per week crashes with the exception OutOfMemoryError: GC overhead limit exceeded. I'm trying to figure out what's wrong there. I made dump of memory and made histogram of all used classes (I used jmap -histo). And I found very weird results:

Object Histogram:

num       #instances    #bytes  Class description
--------------------------------------------------------------------------
1:              24023   787570032       scala.concurrent.forkjoin.ForkJoinTask[]
2:              96965   12420368        * MethodKlass
3:              96965   11250824        * ConstMethodKlass
4:              8424    8652552 * ConstantPoolKlass
5:              8424    7547640 * InstanceKlassKlass
6:              61739   5531288 char[]
7:              7527    4799776 * ConstantPoolCacheKlass
8:              24024   4612608 scala.concurrent.forkjoin.ForkJoinPool$WorkQueue
9:              27289   3543672 byte[]
10:             23190   2597280 scala.concurrent.impl.ExecutionContextImpl$DefaultThreadFactory$$anon$2
11:             63921   2045472 java.util.concurrent.ConcurrentHashMap$HashEntry
12:             3735    1470112 * MethodDataKlass
13:             42877   1029048 scala.collection.immutable.$colon$colon
14:             8834    1023064 java.lang.Class

So, there are a lot of instances of ForkJoinTask[] and ForkJoinPool$WorkQueue. So, I'm assuming, that it's queues and tasks for all my async calls and threads of the app. And I also think, in theory, they should be removed directly after they've been completed.

What could be possible reasons of this issue? Maybe I missconfigured an ExecutionContext? Does anybody faced to this problem previously?

Denis
  • 61
  • 1
  • 5
  • and what's your particular ExecutionContext configuration? – ale64bit Jan 16 '15 at 13:12
  • I didn't do any extra configuration. Just left it empty: {}. I thought, default params should be suitable for me. – Denis Jan 16 '15 at 13:31
  • well, they usually are, but I thought you had customized it, since you mentioned that `"Maybe I missconfigured an ExecutionContext?"` :S – ale64bit Jan 16 '15 at 13:56

2 Answers2

0

Which context are you using? According to the documentation, you should use 

play.api.libs.concurrent.Execution.Implicits.defaultContext

instead of default 

scala.concurrent.ExecutionContext.Implicits.global

See this answer for an explication.

Community
  • 1
  • 1
KaC
  • 613
  • 6
  • 14
0

The issue was resolved by using the latest version of "scala-reflect" library (version later then 2.11.6):

val scalaV = "2.11.6"

scalaVersion := scalaV

libraryDependencies ++= Seq(
  "org.scala-lang" % "scala-reflect" % scalaV
)

Here is the bug description: https://issues.scala-lang.org/browse/SI-8946

Denis
  • 61
  • 1
  • 5
  • Are you sure this additional library solves your problem? I didn't find the place where you call this library. Can you give me some detailed explanation. Because currently i also meet this performance issue. Thanks. – Haimei Jan 05 '16 at 03:54
  • Well, in that concrete case my app used libraries, which were dependent on the older version of scala-reflect (and that older version contains that [bug](https://issues.scala-lang.org/browse/SI-8946)). So, when I specified explicitly which version of scala-reflect should be used, the problem was resolved. – Denis Jan 08 '16 at 19:05