avoid some LazyVals, prefer AbstractFunction#9216
Merged
lrytz merged 1 commit intoscala:2.12.xfrom Sep 21, 2020
Merged
Conversation
…w that we always need the value Inherit from AbstractFunctionX, rather than FunctionX to reduce bytecode
lrytz
reviewed
Sep 21, 2020
| var result = 0 | ||
| override def apply(v1: A): Unit = result += 1 | ||
| } | ||
| val counter = new counter |
Member
There was a problem hiding this comment.
what do you think about
Suggested change
| val counter = new counter | |
| val counter = new AbstractFunction1[A, Unit] { | |
| var result = 0 | |
| override def apply(v1: A): Unit = result += 1 | |
| } |
Contributor
Author
There was a problem hiding this comment.
The problem with you suggestion is that result is not part of the signature if AbstractFunction1and is therefore read by reflection code that the compiler generates
LINENUMBER 140 L5
ALOAD 1
ASTORE 2
L0
ALOAD 2
INVOKEVIRTUAL scala/runtime/AbstractFunction1.getClass ()Ljava/lang/Class;
INVOKESTATIC scala/collection/TraversableOnce.reflMethod$Method1 (Ljava/lang/Class;)Ljava/lang/reflect/Method; (itf)
ALOAD 2
ICONST_0
ANEWARRAY java/lang/Object
INVOKEVIRTUAL java/lang/reflect/Method.invoke (Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
L1
GOTO L6
L2
FRAME FULL [scala/collection/TraversableOnce scala/collection/TraversableOnce$$anon$1 scala/collection/TraversableOnce$$anon$1] [java/lang/reflect/InvocationTargetException]
ASTORE 3
ALOAD 3
INVOKEVIRTUAL java/lang/reflect/InvocationTargetException.getCause ()Ljava/lang/Throwable;
ATHROW
L6
FRAME SAME1 java/lang/Object
CHECKCAST java/lang/Integer
L7
INVOKESTATIC scala/runtime/BoxesRunTime.unboxToInt (Ljava/lang/Object;)I
L8
IRETURN
and
// access flags 0x9
public static reflMethod$Method1(Ljava/lang/Class;)Ljava/lang/reflect/Method;
// parameter final x$1
L0
LINENUMBER 140 L0
INVOKEDYNAMIC apply()Lscala/runtime/StructuralCallSite; [
// handle kind 0x6 : INVOKESTATIC
scala/runtime/StructuralCallSite.bootstrap(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
// arguments:
()Ljava/lang/Object;
]
ASTORE 1
L1
ALOAD 1
ALOAD 0
INVOKEVIRTUAL scala/runtime/StructuralCallSite.find (Ljava/lang/Class;)Ljava/lang/reflect/Method;
ASTORE 2
L2
ALOAD 2
IFNULL L3
ALOAD 2
ARETURN
L3
FRAME APPEND [scala/runtime/StructuralCallSite java/lang/reflect/Method]
GETSTATIC scala/runtime/ScalaRunTime$.MODULE$ : Lscala/runtime/ScalaRunTime$;
ALOAD 0
LDC "result"
ALOAD 1
INVOKEVIRTUAL scala/runtime/StructuralCallSite.parameterTypes ()[Ljava/lang/Class;
INVOKEVIRTUAL java/lang/Class.getMethod (Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
INVOKEVIRTUAL scala/runtime/ScalaRunTime$.ensureAccessible (Ljava/lang/reflect/Method;)Ljava/lang/reflect/Method;
ASTORE 2
ALOAD 1
ALOAD 0
ALOAD 2
INVOKEVIRTUAL scala/runtime/StructuralCallSite.add (Ljava/lang/Class;Ljava/lang/reflect/Method;)Ljava/lang/reflect/Method;
POP
ALOAD 2
ARETURN
L4
LOCALVARIABLE methodCache1 Lscala/runtime/StructuralCallSite; L1 L4 1
LOCALVARIABLE method1 Ljava/lang/reflect/Method; L2 L4 2
LOCALVARIABLE x$1 Ljava/lang/Class; L0 L4 0
MAXSTACK = 4
MAXLOCALS = 3
lrytz
approved these changes
Sep 21, 2020
finaglehelper
pushed a commit
to twitter/finatra
that referenced
this pull request
Mar 11, 2021
Problem ======= Upgrade source to https://github.com/scala/scala/releases/tag/v2.12.13 from https://github.com/scala/scala/releases/tag/v2.12.12. This upgrade includes a highlighted feature of configurable warnings and errors (https://www.scala-lang.org/2021/01/12/configuring-and-suppressing-warnings.html / scala/scala#9248). Other noticable changes our code based will experience * Exhaustivity warnings for patterns involving tuples * Better type checking for `CharSequence` arguments scala/scala#9292 * Simplified Reporters scala/scala#8338 * Promotion of `-deprecation` to `-Xlint:deprecation` scala/scala#7714 * Improves performance of building `immutable.{TreeMap,TreeSet}` by using mutation within the builder scala/scala#8794 Full list of changes can be found at https://github.com/scala/scala/pulls?q=is%3Amerged+milestone%3A2.12.13+ Solution ======== * Bump `BUILD` file `SCALA_REV` && `SCALAC_REV_FOR_DEPS`. * Depdnencies which are not built for scala 2.12.13 needed to be bumped `SEMANTICDB_PLUGIN_REV` && `SEMANTICDB_REV` && `SCALAFIX_REV`. * Include `-S-Xlint:-deprecation` to `pants.ini` preventing build failures on deprecated annotations (existing behavior) * Bump `cache_key_gen_version` in `pants.ini` for newly built artifacts on different scala version. * Removed scalafix plugin (`scalac-profiling`) which is not built for 2.12.13. `scalac-profiling` code looks abandoned by ~3 years. * Updated all failing tests that could have depended or expected ordered sequences when the sequence was generated from non ordered collections. Notes ===== It seems a few tests and golden files in source have depended or tested against a stable sort order when sorted order is not guaranteed. This has been seen in a few places such as output json objects (map key fields), code that uses `groupBy` for rekeying results to the user and transforming into sequences, strings built from sequences or maps that are not guaranteed to be ordered. The following PR are related to this change in expectations scala/scala#8794 scala/scala#8948 scala/scala#9218 scala/scala#9376 scala/scala#9091 scala/scala#9216 We took the liberty updating tests with what the current map order would be or updating the test in a way that wouldn't depend on order. Since we may not fully understand all the context of the tests we are hoping this either signals to the owners that there might be some issue with assumed order or signal that upgrading might break implementations due to bug in scala 2.12.13. {D611202} will improve the files changed for workflow builder outside of this change. Please feel to reach out directly and discuss the changes here or bring up issues with this upgrade. Slack [[https://app.slack.com/client/T86S8GHEG/C01NZAFRLFK|#scala-upgrade-2-12-13]] JIRA Issues: SCALA-25 Differential Revision: https://phabricator.twitter.biz/D607826
hamzaremmal
pushed a commit
to hamzaremmal/scala3
that referenced
this pull request
May 2, 2025
…ions avoid some LazyVals, prefer AbstractFunction
hamzaremmal
pushed a commit
to scala/scala3
that referenced
this pull request
May 7, 2025
…ions avoid some LazyVals, prefer AbstractFunction
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
use a class and a val to avoid the allocation of a LazyRef when w know that we always need the value
Inherit from AbstractFunctionX, rather than FunctionX to reduce bytecode