Thanks to visit codestin.com
Credit goes to github.com

Skip to content

WiP Separate the scalalib from the Scala.js library. #4787

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

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Jan 14, 2023

See scala/improvement-proposals#54

For now this is only the first step: applying the IR cleaner to the scalalib so that it does not refer to the Scala.js library anymore. It is still bundled in the same artifact.

I identified two annoying things:

  • We have to abandon the Scala.js-specific optimization of mutable.Buffer. Not sure how much good that did.
  • We have to disable the optimization of Scala varargs using a js.Array-based seq.

Other than that, it is a bit of copy-paste, but not too bad.

@gzm0 Opinions on how this looks so far?

@gzm0
Copy link
Contributor

gzm0 commented Jan 15, 2023

I agree with you overall assessment of what is problematic. Do we have any chance of benchmarking whether it matters?

  • For vararg optimization I guess it's only a code size concern.
  • For mutable.Buffer maybe some performance benchmarking would be nice :-/

@sjrd sjrd force-pushed the separate-scalalib branch from 613cd6d to 5d7c381 Compare January 17, 2023 15:01
@sjrd
Copy link
Member Author

sjrd commented Jan 19, 2023

For vararg optimization I guess it's only a code size concern.

Paradoxically, it improves code size in 2.12 (but worsens it in 2.13). Less things can be inlined as local loops because of that change. IMO it's more for performance: js.ArrayWrapper is a lighter wrapper than ArrayOps (which is a wrapper over an Array, itself a wrapper on a JS Array).

For mutable.Buffer maybe some performance benchmarking would be nice :-/

Yes, but we never had any benchmarks for that. scalajs-benchmark has benchmarks for immutable collections only. mutable.Buffer in particular is a bit weird because we decided to (hopefully) optimize it based on a "it would be nice". If it happened today, I don't think we would make that change like that.

@gzm0
Copy link
Contributor

gzm0 commented Feb 6, 2023

Paradoxically, it improves code size in 2.12 (but worsens it in 2.13). Less things can be inlined as local loops because of that change. IMO it's more for performance: js.ArrayWrapper is a lighter wrapper than ArrayOps (which is a wrapper over an Array, itself a wrapper on a JS Array).

Feels like we should make scala.Array @inline :)

@sjrd
Copy link
Member Author

sjrd commented Feb 6, 2023

scala.Array is magic. It doesn't exist as a class in the IR. But we might want to virtualize ArrayValue nodes in the optimizer in the same way that we virtualize JSArray nodes.

sjrd added 7 commits October 27, 2023 17:31
This way, we have only one implementation for all the versions of
Scala. This will become more useful as we make its implementation
less trivial.

We also rename it back to `UniquenessCache`, which is the name it
has on the JVM, and reinstate the `Null` lower bound on `V`. There
was no reason to name it differently, and keeping the name may be
better for binary compatibility (even though it is `private[scala]`
and nobody should be using it). It is still different for the key
type, which is fixed to `String`.
They were changed in 757949e to
use a `js.WrappedArray` by default, instead of an `ArrayBuffer`.

Unfortunately, if we want to make the scalalib independent from the
Scala.js library, this is not something we can do anymore.

Ideally, we would override `ArrayBuffer` itself with an
implementation based on `js.Array`. We cannot do that either
because its `array` field is protected, and it is not final.
It has specific overrides in `overrides-2.12` and `overrides-2.13`.
…obal`.

This is required not to depend on the Scala.js library from
`ExecutionContext`.
This removes references to run-time components of
`js.WrappedDictionary` that the IR cleaner cannot get rid of.
We use it in the scalalib, so that we do not generate references
to `toScalaVarArgs`, which uses custom collections from the
Scala.js library.
It is configured differently than for the javalib. We allow
references to `scala.*` (obviously) but disallow references to
`scala.scalajs.*`. We also avoid rewriting Scala functions to JS
functions, since that changes the binary APIs.

We use a local copy of `sjs.runtime.AnonFunctionN` classes in
`scala.runtime.*` to support the codegen of lambdas.
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.

2 participants