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

Cache Scala.js Linker to enable incremental linking #1007

Merged
merged 2 commits into from
Nov 24, 2020

Conversation

lolgab
Copy link
Member

@lolgab lolgab commented Nov 20, 2020

Originated from this message on gitter.im.
This should solve the problem.

This PR caches all the linkers separately. For now there are 12 combinations. But adding new parameters could explode the possibilities even more.
I did this so you can jump between different settings of fastOpt/fullOpt, ModuleKind without losing the incremental linking.

@lolgab lolgab marked this pull request as ready for review November 21, 2020 07:36
Copy link
Member

@lefou lefou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
Do you have any numbers or estimates, what the memory consumption of a cached linker is, and how much speed we gain by caching? My initial though was, that a module-local worker should be enough to cache the linker, but it might be wrong.

@lolgab
Copy link
Member Author

lolgab commented Nov 24, 2020

Do you have any numbers or estimates, what the memory consumption of a cached linker is, and how much speed we gain by caching?

I don't. Let me run some tests and I'll let you know.

My initial though was, that a module-local worker should be enough to cache the linker, but it might be wrong.

I don't know if that works because it is common to run fastOpt/fullOpt on the same module.

@lolgab
Copy link
Member Author

lolgab commented Nov 24, 2020

Didn't measure the speedup but it's apparent using it.
About memory consumption, a linker instance goes from ~60Mb (fastOpt) to ~120Mb(fullOpt) for a small/medium sized Scala.js application:
image

These four are for the CommonJSModule/NoModule - fastOpt/fullOpt matrix

@lefou
Copy link
Member

lefou commented Nov 24, 2020

Thanks for the numbers, @lolgab ! IMHO, this is already some significant memory, given, that we also keep cached Scala compilers and probably other tools around. Maybe, we can keep WeakReferences of the linker, so that the JVM has some options when in trouble. We already do this in ZincWorkerImpl.

@lolgab
Copy link
Member Author

lolgab commented Nov 24, 2020

Didn't know about the WeakReference trick. Nice!
Used it and changed the cache to a mutable.Map following ZincWorkerImpl.

- Use mutable.Map instead of immutable as cache
@lolgab lolgab force-pushed the cache-scala-js-linker-instance branch from 89b116a to 0268586 Compare November 24, 2020 10:29
@lefou
Copy link
Member

lefou commented Nov 24, 2020

Thank you! I'm going to merge after the CI has finished. Travis-CI is currently disabled, so I'm going to start the CI job on my fork.

@lolgab
Copy link
Member Author

lolgab commented Nov 24, 2020

@lefou All the relevant jobs are green ✅
image
https://travis-ci.org/github/lefou/mill/builds/745613555

@lefou lefou merged commit 58503e1 into com-lihaoyi:master Nov 24, 2020
@lefou lefou added this to the after 0.8.0 milestone Nov 24, 2020
@lolgab lolgab deleted the cache-scala-js-linker-instance branch November 24, 2020 14:25
@lolgab
Copy link
Member Author

lolgab commented Nov 24, 2020

Thank you for the review as usual @lefou 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants