Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OutOfMemoryError in patmat on 2.11.0 #8531

Closed
scabug opened this issue Apr 24, 2014 · 17 comments
Closed

OutOfMemoryError in patmat on 2.11.0 #8531

scabug opened this issue Apr 24, 2014 · 17 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Apr 24, 2014

We have a codebase, called "antigone" which is caused the patmat phase of compilation to throw an OutOfMemoryError when compiled with -Xmx2g, where previously it would compile just fine with -Xmx700m (I have had to make no code changes as part of the upgrade).

I am privately sending Jason a heap dump from the profiler

@scabug
Copy link
Author

scabug commented Apr 24, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8531?orig=1
Reporter: @oxbowlakes
Affected Versions: 2.11.0
See #7020
Attachments:

  • foobar.jar (created on May 7, 2014 10:07:31 AM UTC, 5071 bytes)
  • MyEnum.java (created on May 7, 2014 10:07:31 AM UTC, 1101 bytes)
  • SI8531.scala (created on May 7, 2014 10:13:24 AM UTC, 525 bytes)
  • WriteEnum.scala (created on May 7, 2014 10:06:53 AM UTC, 505 bytes)

@scabug
Copy link
Author

scabug commented Apr 24, 2014

@retronym said:
The heap dump shows about 188k strongly reachable instances of Solving$SolverLit, an internal data structure in the pattern matcher used to calculating exhaustivity / reachability of matches.

What is the minimum memory needed to compile? Does, say, 1.2G work?

It would be good to track this down to a smaller test case.

A blackbox way to do this:

SOURCES=$(find src -name '*.scala')
CP=foo.jar:bar.jar
echo jointly compiling everthing with copious memory
scalac J-Xmx4G -d target/classes -classpath $CP ... $SOURCES
for s in $SOURCES; do
  echo individually compiling $s with limited memory
  scalac J-Xmx500M -classpath target/classes:$CP $s
done

Looking at your heap dump, it looks like the OOME was triggered during:

antigone\src\gsa\antigone\angkor\transmission.scala

But that's not 100% reliable, something could have leaked before then and that file was just the straw that broke the camel's back.

Can you also please try compiling with scalac -Dscalac.patmat.analysisBudget=0 which turns of the pattern matcher analysis.

@scabug
Copy link
Author

scabug commented Apr 24, 2014

@retronym said:
I suspect that #7020 / scala/scala@69557da might be to blame for a constant-factor increase in space usage.

@scabug
Copy link
Author

scabug commented Apr 24, 2014

@retronym said:
Oh I misread your comment, it still doesn't compile with a 2G heap.

@scabug
Copy link
Author

scabug commented Apr 24, 2014

@retronym said:
Here's a hit-and-hope: scala/scala#3696

@scabug
Copy link
Author

scabug commented Apr 25, 2014

@oxbowlakes said:
Hi Jason -

I don't know whether what you've identified would reveal the expected behaviour. Basically, most of our codebases seem to be trivially migratable and the compile times have not noticeably changed. But some have gone thru the roof - so it feels like some exponential problem in the patmat phase.

I can get the source to compile here with a 3Gb heap

Chris

@scabug
Copy link
Author

scabug commented Apr 25, 2014

@retronym said:
Can you at least pin it down to a particular file with my suggestion above? Otherwise I'm not really sure how to help more.

@scabug
Copy link
Author

scabug commented Apr 25, 2014

@oxbowlakes said:
Is there any logging I can turn on for patmat? We might at least see it say "I'm about to do tackle this file..."

I've looked at the file you suggested and there is nothing obvious in there (I've tried constructing a minimal case). The construction of the project means that there are a lot of packages with very similar, but not identical code :-s

When I've some spare time next week, I will strip out the packages other than "common" and add them one by one to hopefully narrow it down

@scabug
Copy link
Author

scabug commented Apr 25, 2014

@retronym said:
My suggestion was to compile each file one at a time. This should identify the memory intensive one.

But you can also enable -Ypatmat-debug to (tons of) logs from the pattern matcher.

@scabug
Copy link
Author

scabug commented May 7, 2014

@oxbowlakes said:
Hi - I've isolated this to a (not particularly complicated) pattern match on a "large" Java enum (i.e. one with hundreds of values). I'm just cobbling together something to reproduce it

@scabug
Copy link
Author

scabug commented May 7, 2014

@retronym said:
Great!

I suspect that you could workaround the problem by changing:

val x: LargeEnum = ...
x match { case V1 => ;case V2; ... }
// will disable the analysis for exhaustiveness
(x: Any) match { case V1 => ;case V2; ... }

@scabug
Copy link
Author

scabug commented May 7, 2014

@oxbowlakes said (edited on May 7, 2014 10:15:45 AM UTC):
OK - here we go. I've attached a number of files. The behaviour only seems to manifest itself when scalac is not also compiling the Enum.

WriteEnum.scala - if you compile & run this, it will generate a file C:/tmp/SI8531/foobar/MyEnum.java (I've attached this file)

Open a command prompt on C:/tmp/SI8531 and run the following:

C:\tmp\SI8531>javac foobar\MyEnum.java
C:\tmp\SI8531>jar cvf foobar.jar foobar/MyEnum.class
added manifest
adding: foobar/MyEnum.class(in = 10238) (out= 4603)(deflated 55%)

(I've attached foobar.jar so you can skip this step)

Now try and compile SI8531.scala with foobar.jar on the classpath - it takes ages. (Equivalently, you can skip the creation of the JAR and just compile SI8531 with the directory C:/tmp/SI8531 on the classpath)

@scabug
Copy link
Author

scabug commented May 8, 2014

@retronym said (edited on May 8, 2014 2:30:02 PM UTC):
Thanks for the test case.

The OOME appeared after: scala/scala@69557da

% javac -d /tmp test/files/pos/t8531/MyEnum.java && time scalac-hash 69557da5539a5a5132100fdab931e69f82139e15 -classpath /tmp test/files/pos/t8531/Test.scala
[info] downloading http://scala-webapps.epfl.ch/artifacts/69557da5539a5a5132100fdab931e69f82139e15/pack.tgz ...done.
[info] scala revision from 2013-10-22 10:15:59 +0200 downloaded to /Users/jason/usr/scala-v2.11.0-M6-80-g69557da
Password:
error: java.lang.OutOfMemoryError: Java heap space

% javac -d /tmp test/files/pos/t8531/MyEnum.java && time scalac-hash 69557da5539a5a5132100fdab931e69f82139e15~1 -classpath /tmp test/files/pos/t8531/Test.scala
[info] downloading http://scala-webapps.epfl.ch/artifacts/90d6605d88ee01cb7e1e8761cc82ba28c8575d27/pack.tgz ...done.
[info] scala revision from 2013-10-21 14:03:11 -0700 downloaded to /Users/jason/usr/scala-v2.11.0-M6-79-g90d6605

real	0m38.333s
user	0m12.752s
sys	0m1.235s

# Still memory hungry in 2.11.1-SNAPSHOT
% javac -d /tmp test/files/pos/t8531/MyEnum.java && time scalac-hash origin/2.11.x -classpath /tmp test/files/pos/t8531/Test.scala [info] downloading http://scala-webapps.epfl.ch/artifacts/251616a107f4255203e318c9f6342f774d25e66d/pack.tgz ...done.
[info] scala revision from 2014-05-02 17:49:41 +0200 downloaded to /Users/jason/usr/scala-v2.11.0-37-g251616a
error: java.lang.OutOfMemoryError: Java heap space

@scabug
Copy link
Author

scabug commented May 8, 2014

@retronym said:
Good news: my speculative patch restores 2.10.4 performance for this test case.

New PR that includes the test: scala/scala#3727

@scabug
Copy link
Author

scabug commented May 15, 2015

@oxbowlakes said (edited on May 15, 2015 4:01:39 PM UTC):
This has regressed in at scala 2.11.4 and later (definitely 2.11.5 and 6, anyway)

@scabug
Copy link
Author

scabug commented May 18, 2015

@retronym said:
Your test case is part of our test suite and still passes. I wonder if you are seeing a different regression.

We have a performance fix for the pattern matcher merged in preparation for 2.11.7. scala/scala#4379

Would you be able to retest with 2.11.7-SNAPSHOT?

@scabug
Copy link
Author

scabug commented Jan 29, 2016

@retronym said:
@oxbowlakes Hey Chris, I'm going to reclose this, but I'd invite you to have another go at trying to reproduce this with the latest build and to open a new ticket if something is still broken or has regressed.

@scabug scabug closed this as completed Jan 29, 2016
@scabug scabug added this to the 2.11.1 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants