-
Notifications
You must be signed in to change notification settings - Fork 323
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
Avoid AliasAnalysis for Hello_World.enso #10996
Avoid AliasAnalysis for Hello_World.enso #10996
Conversation
1635cd6
to
dfe42a8
Compare
val packageRepository = compiler.getPackageRepository | ||
this.toConcrete(packageRepository.getModuleMap) | ||
this.pendingRepository = compiler.getPackageRepository | ||
Some(this) |
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.
This is the core of the change. Delaying toConcrete
until all modules are registered to package repository.
It is also potentially dangerous change. Previously, when the restoreFromSerialization
failed, it would return None
and that would trigger parsing. Right now we optimistically claim everything is all right and then we may get failures later when someone calls for example ResolvedModule.unsafeModule
.
It is probably OK (everything is green; but we aren't testing broken scenarios much), but we should get ready for such reports in the future and fix them when they appear.
context.logSerializationManager( | ||
Level.WARNING, | ||
"Deserialization of " + module.getName() + " failed", | ||
ex |
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.
@hubertp, when this exception is logged, the stack trace isn't printed on the console. What's the recommended way of logging an exception with stacktrace via context.logSerializationManager
?
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 don't think I'm surprised anymore. It looks like the included application.conf
does not redefine the layout of logging, meaning it does not print exceptions.
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 will file a separate ticket to enable those. Right now the default and only appender is console. We could easily log those to the file but I'm still against printing those in the console.
There is 5% speedup on obviously |
I don't trust local benchmarking, but per @Akirathan request I did one: Old Run
New run
The benchmark fluctuates a lot, but there seems to be no slowdown and possibly there is some speedup. |
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.
Minor Scala style issues
engine/runtime-compiler/src/main/scala/org/enso/compiler/data/BindingsMap.scala
Outdated
Show resolved
Hide resolved
engine/runtime-compiler/src/main/scala/org/enso/compiler/data/BindingsMap.scala
Outdated
Show resolved
Hide resolved
engine/runtime-compiler/src/main/scala/org/enso/compiler/data/BindingsMap.scala
Outdated
Show resolved
Hide resolved
context.logSerializationManager( | ||
Level.WARNING, | ||
"Deserialization of " + module.getName() + " failed", | ||
ex |
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 will file a separate ticket to enable those. Right now the default and only appender is console. We could easily log those to the file but I'm still against printing those in the console.
Jaroslav Tulach reports a new STANDUP for yesterday (2024-09-06): Progress: .
|
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. Minor nitpicks.
Pull Request Description
Fixes #10843 in an even better way then #10906. At the end of work on #10906 it has been found that
AliasAnalysis
is still used forHello_World.enso
. Mostly because when loading its.ir
cache, we cannot resolve itsStandard.Base.IO
import as nobody loaded theStandard.Base
package into the system yet. This PR fixes the problem by delaying resolution ofBindingsMap
internals until one of its getters is called.At the end
Hello_World
loads its.ir
caches properly without invoking anyAliasAnalysis
functionality as verified by checking the logs.Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
Steps to Reproduce
The ultimate way to verify the behavior is in debugger. Place a breakpoint to
Graph.scala:12
- it should get trigger only once whenLocalScope.empty
is being created. Possibly also for the second time when execution is over and #10842 kicks in (this second case can be disabled by using--repl
for example).To reproduce from CLI run twice (first run generates the
.ir
cache) and then checks the logs:prior to this PR the log contains:
with this PR the log contains: