-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Emit local module like lazy val #5430
Conversation
There's still a lot of duplication, as well as plenty of opportunities for constant folding / simplification.
I couldn't help but make some constants final in d04cda1 when I was fixing the name of the val in the expansion. @retronym, @lrytz: any reservations about this? The outer pointer being null is progress, actually, since delambdafy correctly elides it. I added a test case where it isn't elided because it's used. |
/rebuild Hrm. Is the ec2 instance type not the issue here? |
|
Right, so that error occurred on the behemoth that had already been upgraded to 4xlarge... |
How come the max heap space is 1024m in that log?
I thought we had it at 2g? |
|
even more numbers if you do the same |
|
consting those strings seems okay to me. |
@@ -632,7 +632,7 @@ lazy val test = project | |||
javaOptions in IntegrationTest += "-Xmx2G", | |||
testFrameworks += new TestFramework("scala.tools.partest.sbt.Framework"), | |||
testFrameworks -= new TestFramework("org.scalacheck.ScalaCheckFramework"), | |||
testOptions in IntegrationTest += Tests.Argument("-Dpartest.java_opts=-Xmx1024M -Xms64M -XX:MaxPermSize=128M"), | |||
testOptions in IntegrationTest += Tests.Argument(s"-Dpartest.java_opts=${(javaOptions in IntegrationTest).value.mkString(" ")}"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a small initial heap for all the forked partest processes seems desirable to me, this change drops that:
show test/it:javaOptions
[info] List(-Xmx2G)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we actually have partests that require large heaps, we should probably segregated them into a new category that is run sequentially. That would let us run the vast majority of them with a small heap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of a large heap section.
Regarding the initial heap size, after this PR it would be 472M according to java -Xmx2g -XX:+PrintFlagsFinal
. Should I move the -Xms64m
setting to javaOptions in IntegrationTest += "-Xmx2G",
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, the JVM that forks for the partest framework itself can probably get away with a small heap, too. I have a feeling that we bumped up the flags of that JVM to try to get around intermittent failures that were actually fixed later on this line.
Happy to do whatever gets things working again for 2.12.0 and leave the cleanup work until 2.12.x; I've noted my ideas in scala/scala-jenkins-infra#181 (comment)
e025648
to
9c738a1
Compare
Still failing. Very hard from the output to see which JVM is actually heap bound. Should we add |
Added it to the tests, for a start. No idea what's going on here. This is running on an EC2 c4.4xlarge instance, which has 30G ram. |
We'll have to wait until we can upgrade to a b92 or later jdk for the crash on out of memory option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, also the name constants.
I don't understand what you're referring to by "outer pointer being null is progress / added a test case"
@@ -541,10 +536,13 @@ abstract class Fields extends InfoTransform with ast.TreeDSL with TypingTransfor | |||
* } | |||
* def x(): Int = if (x$lzy.initialized()) x$lzy.value() else x$lzycompute() | |||
* ``` | |||
* | |||
* The expansion is the same for local lazy vals and local objects, | |||
* except for the name of the val ($lzy or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or? $module
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
darn, yes, or $module
:-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
I was surprised by the diff in generated code for a local test I was doing, but forgot you can't see my screen, so yeah, that was a mysterious comment 😎 The test looked something like In that test, the outer pointer passed to the local module's class's constructor is now |
The motivation is to use the new fine-grained lock scoping that local lazies have since scala#5294. Fixes scala/scala-dev#235 Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
A local lazy val and a local object are expanded in the same way.
I dropped all the CI-related stuff (moved discussion to scala/scala-dev#236) and fixed the doc |
The motivation is to use the new fine-grained lock scoping that
local lazies have since #5294.
Fixes scala/scala-dev#235
Co-Authored-By: Jason Zaugg jzaugg@gmail.com
Review by @adriaanm
TODO:
null
:(C$O$2$)O$lzy$1.initialize((Object)new C$O$2$(null));
versusx$1.elem = new C$O$2$(this);
O$module
->O$lzy
Follow up for #5428