summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/backend/jvm/BTypesFromSymbols.scala
Commit message (Collapse)AuthorAgeFilesLines
* SI-8779 Enable inlining of code within a REPL sessionJason Zaugg2016-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | The REPL has a long running instance of Global which outputs classfiles by default to a VirtualDirectory. The inliner did not find any of these class files when compiling calls to methods defined in previous runs (ie, previous lines of input.) This commit: - Adds a hook to augment the classpath that the optimizer searches, and uses this in the REPL to add the output directory - Fixes the implementation of `findClassFile` in VirtualDirectory, which doesn't seem to have been used in anger before. I've factored out some common code into a new method on `AbstractFile`. - Fixes a similar problem getSubDir reported by Li Haoyi - Adds missing unit test coverage. This also fixes a bug in REPL autocompletion for types defined in packages >= 2 level deep (with the `:paste -raw` command). I've added a test for this case.
* Optimize javaBinaryName callersJason Zaugg2016-09-261-3/+3
| | | | | | | ... by calling javaBinaryNameString, instead. They all are happy with a throw away String, there is no advantage to interning this into the name table.
* SD-192 Change scheme for trait super accessorsJason Zaugg2016-08-151-1/+1
| | | | | | Rather than putting the code of a trait method body into a static method, leave it in the default method. The static method (needed as the target of the super calls) now uses `invokespecial` to exactly call that method.
* Merge pull request #5291 from lrytz/sd20Adriaan Moors2016-08-121-1/+8
|\ | | | | | | | | SD-20 Inlcude static methods in the InlineInfo in mixed compilation Fixes scala/scala-dev#20
| * SD-20 Inlcude static methods in the InlineInfo in mixed compilationLukas Rytz2016-07-191-1/+8
| | | | | | | | | | | | | | | | In mixed compilation, the InlineInfo for a Java-defined class is created using the class symbol (vs in separate compilation, where the info is created by looking at the classfile and its methods). The scala compiler puts static java methods into the companion symbol, and we forgot to include them in the list of methods in the InlineInfo.
* | Reduce flag fiddlingAdriaan Moors2016-08-111-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There isn't much point to the late* flags in a world where we're mutating flags left and right in tree and info transformers... So, lets get rid of the indirection until we can include flags in a symbol's type history, like we do for its info. This retires lateDEFERRED (redundant with SYNTHESIZE_IMPL_IN_SUBCLASS). Since it's introduced so late, it makes little sense to have these synthetic members go back to DEFERRED. Instead, just set DEFERRED directly. Also remove unused late* and not* flags. notPRIVATE subsumes lateFINAL for effective finality (scala/scala-dev#126)
* | Fields phaseAdriaan Moors2016-08-111-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One step towards teasing apart the mixin phase, making each phase that adds members to traits responsible for mixing in those members into subclasses of said traits. Another design tenet is to not emit symbols or trees only to later remove them. Therefore, we model a val in a trait as its accessor. The underlying field is an implementation detail. It must be mixed into subclasses, but has no business in a trait (an interface). Also trying to reduce tree creation by changing less in subtrees during tree transforms. A lot of nice fixes fall out from this rework: - Correct bridges and more precise generic signatures for mixed in accessors, since they are now created before erasure. - Correct enclosing method attribute for classes nested in trait fields. Trait fields are now created as MethodSymbol (no longer TermSymbol). This symbol shows up in the `originalOwner` chain of a class declared within the field initializer. This promoted the field getter to being the enclosing method of the nested class, which it is not (the EnclosingMethod attribute is a source-level property). - Signature inference is now more similar between vals and defs - No more field for constant-typed vals, or mixed in accessors for subclasses. A constant val can be fully implemented in a trait. TODO: - give same treatment to trait lazy vals (only accessors, no fields) - remove support for presuper vals in traits (they don't have the right init semantics in traits anyway) - lambdalift should emit accessors for captured vals in traits, not a field Assorted notes from the full git history before squashing below. Unit-typed vals: don't suppress field it affects the memory model -- even a write of unit to a field is relevant... unit-typed lazy vals should never receive a field this need was unmasked by test/files/run/t7843-jsr223-service.scala, which no longer printed the output expected from the `0 to 10 foreach` Use getter.referenced to track traitsetter reify's toolbox compiler changes the name of the trait that owns the accessor between fields and constructors (`$` suffix), so that the trait setter cannot be found when doing mkAssign in constructors this could be solved by creating the mkAssign tree immediately during fields anyway, first experiment: use `referenced` now that fields runs closer to the constructors phase (I tried this before and something broke) Infer result type for `val`s, like we do for `def`s The lack of result type inference caused pos/t6780 to fail in the new field encoding for traits, as there is no separate accessor, and method synthesis computes the type signature based on the ValDef tree. This caused a cyclic error in implicit search, because now the implicit val's result type was not inferred from the super member, and inferring it from the RHS would cause implicit search to consider the member in question, so that a cycle is detected and type checking fails... Regardless of the new encoding, we should consistently infer result types for `def`s and `val`s. Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c, since they were relying on inferring argument types from "overridden" constructors in a test for range positions of default arguments. Constructors don't override, so that was a mis-feature of -Yinfer-argument-types. Had to slightly refactor test/files/presentation/doc, as it was relying on scalac inferring a big intersection type to approximate the anonymous class that's instantiated for `override lazy val analyzer`. Now that we infer `Global` as the expected type based on the overridden val, we make `getComment` private in navigating between good old Skylla and Charybdis. I'm not sure why we need this restriction for anonymous classes though; only structural calls are restricted in the way that we're trying to avoid. The old behavior is maintained nder -Xsource:2.11. Tests: - test/files/{pos,neg}/val_infer.scala - test/files/neg/val_sig_infer_match.scala - test/files/neg/val_sig_infer_struct.scala need NMT when inferring sig for accessor Q: why are we calling valDefSig and not methodSig? A: traits use defs for vals, but still use valDefSig... keep accessor and field info in synch
* | Upgrade asm to 5.1Lukas Rytz2016-07-201-1/+2
|/ | | | | The constructor of scala.tools.asm.Handle now takes an additional boolean parameter to denote whether the owner is an interface.
* Emit trait method bodies in staticsJason Zaugg2016-06-281-2/+78
| | | | | | | | | | | | | | | | | | | | And use this as the target of the default methods or statically resolved super or $init calls. The call-site change is predicated on `-Yuse-trait-statics` as a stepping stone for experimentation / bootstrapping. I have performed this transformation in the backend, rather than trying to reflect this in the view from Scala symbols + ASTs. We also need to add an restriction related to invokespecial to Java parents: to support a super call to one of these to implement a super accessor, the interface must be listed as a direct parent of the class. The static method names has a trailing $ added to avoid duplicate name and signature errors in classfiles.
* Don't minimize parents of java defined syms.Jason Zaugg2016-06-281-1/+2
|
* Rename -Yopt to -opt, -Yopt-warnings to -opt-warningsLukas Rytz2016-05-251-1/+1
| | | | Keep -Yopt-inline-heuristics and -Yopt-trace unchanged
* Remove references to trait impl classes, mostly in doc commentsLukas Rytz2016-04-071-28/+8
|
* SI-9702 Fix backend crash with classOf[T] annotation argumentLukas Rytz2016-03-301-24/+9
| | | | | | | | | | | | | | This commit fixes various issues with classOf literals and Java annotations. - Ensure that a Type within a ConstantType (i.e., a classOf literal) is erased, so `classOf[List[Int]]` becomes `classOf[List]`. - Ensure that no non-erased types are passed to `typeToBType` in the backend. This happens for Java annotations: the annotation type and `classOf` annotation arguments are not erased, the annotationInfos of a symbol are not touched in the compiler pipeline. - If T is an alias to a value class, ensure that `classOf[T]` erases to the value class by calling `dealiasWiden` in erasure.
* New trait encoding: use default methods, jettison impl classesJason Zaugg2016-03-181-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, concrete methods in traits were encoded with "trait implementation classes". - Such a trait would compile to two class files - the trait interface, a Java interface, and - the implementation class, containing "trait implementation methods" - trait implementation methods are static methods has an explicit self parameter. - some methods don't require addition of an interface method, such as private methods. Calls to these directly call the implementation method - classes that mixin a trait install "trait forwarders", which implement the abstract method in the interface by forwarding to the trait implementation method. The new encoding: - no longer emits trait implementation classes or trait implementation methods. - instead, concrete methods are simply retained in the interface, as JVM 8 default interface methods (the JVM spec changes in [JSR-335](http://download.oracle.com/otndocs/jcp/lambda-0_9_3-fr-eval-spec/index.html) pave the way) - use `invokespecial` to call private or particular super implementations of a method (rather `invokestatic`) - in cases when we `invokespecial` to a method in an indirect ancestor, we add that ancestor redundantly as a direct parent. We are investigating alternatives approaches here. - we still emit trait fowrarders, although we are [investigating](https://github.com/scala/scala-dev/issues/98) ways to only do this when the JVM would be unable to resolve the correct method using its rules for default method resolution. Here's an example: ``` trait T { println("T") def m1 = m2 private def m2 = "m2" } trait U extends T { println("T") override def m1 = super[T].m1 } class C extends U { println("C") def test = m1 } ``` The old and new encodings are displayed and diffed here: https://gist.github.com/retronym/f174d23f859f0e053580 Some notes in the implementation: - No need to filter members from class decls at all in AddInterfaces (although we do have to trigger side effecting info transformers) - We can now emit an EnclosingMethod attribute for classes nested in private trait methods - Created a factory method for an AST shape that is used in a number of places to symbolically bind to a particular super method without needed to specify the qualifier of the `Super` tree (which is too limiting, as it only allows you to refer to direct parents.) - I also found a similar tree shape created in Delambdafy, that is better expressed with an existing tree creation factory method, mkSuperInit.
* Use invokedynamic for structural calls, symbol literals, lamba ser.Jason Zaugg2016-01-291-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous encodings created static fields in the enclosing class to host caches. However, this isn't an option once emit code in default methods of interfaces, as Java interfaces don't allow private static fields. We could continue to emit fields, and make them public when added to traits. Or, as chosen in this commit, we can emulate a call-site specific static field by using invokedynamic: when the call site is linked, our bootstrap methid can perform one-time computation, and we can capture the result in the CallSite. To implement this, I've allowed encoding of arbitrary invokedynamic calls in ApplyDynamic. The encoding is: ApplyDynamic( NoSymbol.newTermSymbol(TermName("methodName")).setInfo(invokedType) Literal(Constant(bootstrapMethodSymbol)) :: ( Literal(Constant(staticArg0)) :: Literal(Constant(staticArgN)) :: Nil ) ::: (dynArg0 :: dynArgN :: Nil) ) So far, static args may be `MethodType`, numeric or string literals, or method symbols, all of which can be converted to constant pool entries. `MethodTypes` are transformed to the erased JVM type and are converted to descriptors as String constants. I've taken advantage of this for symbol literal caching and for the structural call site cache. I've also included a test case that shows how a macro could target this (albeit using private APIs) to cache compiled regexes. I haven't managed to use this for LambdaMetafactory yet, not sure if the facility is general enough.
* Merge remote-tracking branch 'upstream/2.12.x' into opt/elimBoxesLukas Rytz2016-01-241-5/+96
|\
| * SI-8700 Exhaustiveness warning for enums from Java sourceSimon Ochsenreither2016-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Until now, the warning was only emitted for enums from Java class files. This commit fixes it by - aligning the flags set in JavaParsers with the flags set in ClassfileParser (which are required by the pattern matcher to even consider checking exhaustiveness) - adding the enum members as childs to the class holding the enum as done in ClassfileParser so that the pattern matcher sees the enum members when looking for the sealed children of a type
| * Remove ICodeSimon Ochsenreither2015-10-311-2/+0
| |
| * Remove GenASM, merge remaining common code snippetsSimon Ochsenreither2015-10-271-2/+95
| | | | | | | | | | | | | | | | With GenBCode being the default and only supported backend for Java 8, we can get rid of GenASM. This commit also fixes/migrates/moves to pending/deletes tests which depended on GenASM before.
* | Harden methods to recognize method invocations to optimizeLukas Rytz2016-01-231-4/+4
|/ | | | | | | | | | | | The previous methods to identify method invocations that can be optimized, such as `isPredefAutoBox`, were String-based. Now we obtain class and method signatures from symbols through the BTypes infrastructure. We also piggy-back on specialization's type transformer to create all specialized subclasses of Tuple1/Tuple2. We'll do the same in the future for FunctionN, but the current JFunctionN are written in Java and specialized artisanally.
* Clean up CoreBTypes, consistent names, remove unused entriesLukas Rytz2015-10-201-6/+6
|
* Simplify and correctify calculation of the InnerClass attributeLukas Rytz2015-10-201-8/+16
| | | | | | | | | | | | | The InnerClass attribute needs to contain an entry for every nested class that is defined or referenced in a class. Details are in a doc comment in BTypes.scala. Instead of collecting ClassBTypes of nested classes into a hash map during code generation, traverse the class before writing it out to disk. The previous approach was incorrect as soon as the generated bytecode was modified by the optimzier (DCE, inlining). Fixes https://github.com/scala/scala-dev/issues/21.
* Rename the Analyzers backend component to BackendUtilsLukas Rytz2015-09-231-3/+3
| | | | | Until now, there was no good place to hold various utility functions that are used acrosss the backend / optimizer.
* Merge pull request #4711 from lrytz/opt/heuristicsLukas Rytz2015-09-221-4/+9
|\ | | | | Inliner heuristic for higher-order methods
| * Run computeMaxLocalsMaxStack less oftenLukas Rytz2015-09-171-0/+3
| | | | | | | | | | | | | | | | | | Introduce a cache to remember which methods have maxLocals and maxStack already computed. Before we were computing these values on every run of eliminateUnreachableCode. Also update the implementation of eliminateUnreachableCode to keep correct max values.
| * Reduce component nesting in backendLukas Rytz2015-09-171-0/+2
| | | | | | | | | | Make InlinerHeuristics a backend component like the others, instead of nested within the Inliner component.
| * Store SAM information in ClassBTypesLukas Rytz2015-08-271-3/+3
| | | | | | | | | | If a class (trait) is a SAM type, store the name and descriptor of the SAM in the ClassBType's InlineInfo.
| * minor clenaupsLukas Rytz2015-08-141-1/+1
| |
* | Allow BCode to emit default interface methodsJason Zaugg2015-08-111-1/+1
|/ | | | | | | | | | A DefDef owned by a trait may now have have a method body. Such a method must be emitted without ACC_ABSTRACT, and with the code attribute. Tested by intercepting the compile pipeline and adding the DEFAULTMETHOD flag and a method body before running the backend.
* Rename the ENUM / DEFAULTMETHOD flags to include JAVA_Lukas Rytz2015-07-221-1/+1
| | | | | Similar to the new JAVA_ANNOTATION flag, be more explicit about flags for java entities.
* SI-9393 fix modifiers of ClassBTypes for Java annotationsLukas Rytz2015-07-221-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scala classfile and java source parsers make Java annotation classes (which are actually interfaces at the classfile level) look like Scala annotation classes: - the INTERFACE / ABSTRACT flags are not added - scala.annotation.Annotation is added as superclass - scala.annotation.ClassfileAnnotation is added as interface This makes type-checking @Annot uniform, whether it is defined in Java or Scala. This is a hack that leads to various bugs (SI-9393, SI-9400). Instead the type-checking should be special-cased for Java annotations. This commit fixes SI-9393 and a part of SI-9400, but it's still easy to generate invalid classfiles. Restores the assertions that were disabled in #4621. I'd like to leave these assertions in: they are valuable and helped uncovering the issue being fixed here. A new flag JAVA_ANNOTATION is introduced for Java annotation ClassSymbols, similar to the existing ENUM flag. When building ClassBTypes for Java annotations, the flags, superclass and interfaces are recovered to represent the situation in the classfile. Cleans up and documents the flags space in the area of "late" and "anti" flags. The test for SI-9393 is extended to test both the classfile and the java source parser.
* SI-9392 Clarify the workaround comment and introduce a devWarningLukas Rytz2015-07-151-8/+8
|
* Merge pull request #4623 from retronym/ticket/9392v2.12.0-M2Adriaan Moors2015-07-131-0/+8
|\ | | | | SI-9392 Avoid crash in GenBCode for incoherent trees
| * SI-9392 Avoid crash in GenBCode for incoherent treesJason Zaugg2015-07-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A macro in shapeless was generating a tree of the form: ``` { class C#2 new C#2 }.setType(C#1) ``` This happened due to an error in the macro; it used untypecheck to try to fix the owner-chain consistency problem, but kept a reference to the previous version of the block-local class symbol `C` and used this in the resulting tree. This commit detects the particular situation we encountered, and avoids the crash by not creating the `NestedInfo` for the `BType` corresponding to `C#1`. The code comment discusses why I think this is safe, and suggests a refactoring that would mean we only ever try to construct `NestedInfo` when we are going to need them.
* | Fix 27 typos (p-r)Janek Bogucki2015-06-301-1/+1
|/
* Merge pull request #4552 from lrytz/opt/closureInliningJason Zaugg2015-06-241-1/+3
|\ | | | | Closure elimination for new backend
| * Rewrite closure invocations to the lambda body methodLukas Rytz2015-06-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an indylambda closure is allocated and invoked within the same method, rewrite the invocation to the implementation method. This works for any indylambda / SAM type, not only Scala functions. However, the Scala compiler (under -Xexperimental) currently desugars function literals for non-FunctionN types to an anonymous class during typer. No testing yet, waiting for FunctionN to become SAMs first. The feature requires scala-java8-compat to be on the classpath and a number of compiler flags: -Ydelambdafy:method -Ybackend:GenBCode -Yopt:closure-elimination -target:jvm-1.8 ➜ scala git:(opt/closureInlining) ant -Dscala-java8-compat.package=1 -Dlocker.skip=1 ➜ scala git:(opt/closureInlining) cd sandbox ➜ sandbox git:(opt/closureInlining) cat Fun.java public interface Fun<T> { T apply(T x); } ➜ sandbox git:(opt/closureInlining) javac Fun.java ➜ sandbox git:(opt/closureInlining) cat Test.scala class C { val z = "too" def f = { val kap = "me! me!" val f: Tuple2[String, String] => String = (o => z + kap + o.toString) f(("a", "b")) } def g = { val f: Int => String = x => x.toString f(10) } def h = { val f: Fun[Int] = x => x + 100 // Java SAM, requires -Xexperimental, will create an anonymous class in typer f(10) } def i = { val l = 10l val f: (Long, String) => String = (x, s) => s + l + z + x f(20l, "n") } def j = { val f: Int => Int = x => x + 101 // specialized f(33) } } ➜ sandbox git:(opt/closureInlining) ../build/quick/bin/scalac -target:jvm-1.8 -Yopt:closure-elimination -Ydelambdafy:method -Ybackend:GenBCode -Xexperimental -cp ../build/quick/scala-java8-compat:. Test.scala ➜ sandbox git:(opt/closureInlining) asm -a C.class ➜ sandbox git:(opt/closureInlining) cat C.asm [...] public g()Ljava/lang/String; L0 INVOKEDYNAMIC apply()Lscala/compat/java8/JFunction1; [ // handle kind 0x6 : INVOKESTATIC java/lang/invoke/LambdaMetafactory.altMetafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite; // arguments: (Ljava/lang/Object;)Ljava/lang/Object;, // handle kind 0x6 : INVOKESTATIC C.C$$$anonfun$2$adapted(Ljava/lang/Object;)Ljava/lang/String;, (Ljava/lang/Object;)Ljava/lang/String;, 3, 1, Lscala/Serializable;.class, 0 ] CHECKCAST scala/Function1 L1 ASTORE 1 L2 ALOAD 1 BIPUSH 10 INVOKESTATIC scala/runtime/BoxesRunTime.boxToInteger (I)Ljava/lang/Integer; ASTORE 2 POP ALOAD 2 INVOKESTATIC C.C$$$anonfun$2$adapted (Ljava/lang/Object;)Ljava/lang/String; CHECKCAST java/lang/String L3 ARETURN [...]
* | Merge pull request #4566 from lrytz/t9359Adriaan Moors2015-06-221-29/+0
|\ \ | |/ |/| SI-9359 Fix InnerClass entry flags for nested Java enums
| * SI-9359 Fix InnerClass entry flags for nested Java enumsLukas Rytz2015-06-191-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The access flags in InnerClass entries for nested Java enums were basically completely off. A first step is to use the recently introduced backend method `javaClassfileFlags`, which is now moved to BCodeAsmCommon. See its doc for an explanation. Then the flags of the enum class symbol were off. An enum is - final if none of its values has a class body - abstract if it has an abstract method (https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9) When using the ClassfileParser: - ENUM was never added. I guess that's just an oversight. - ABSTRACT (together with SEALED) was always added. This is to enable exhaustiveness checking, see 3f7b8b5. This is a hack and we have to go through the class members in the backend to find out if the enum actually has the `ACC_ABSTRACT` flag or not. When using the JavaParser: - FINAL was never added. - ABSTRACT was never added. This commit fixes all of the above and tests cases (Java enum read from the classfile and from source).
* | Fix 36 typos (d-f)Janek Bogucki2015-06-211-1/+1
|/
* Fix illegal inlining of instructions accessing protected membersLukas Rytz2015-05-281-1/+33
| | | | | | | | | | | | | | | | | | | | | | There were two issues in the new inliner that would cause a VerifyError and an IllegalAccessError. First, an access to a public member of package protected class C can only be inlined if the destination class can access C. This is tested by t7582b. Second, an access to a protected member requires the receiver object to be a subtype of the class where the instruction is located. So when inlining such an access, we need to know the type of the receiver object - which we don't have. Therefore we don't inline in this case for now. This can be fixed once we have a type propagation analyis. https://github.com/scala-opt/scala/issues/13. This case is tested by t2106. Force kmpSliceSearch test to delambdafy:inline See discussion on https://github.com/scala/scala/pull/4505. The issue will go away when moving to indy-lambda.
* Clean up the way compiler settings are accessed in the backend.Lukas Rytz2015-04-011-18/+5
| | | | | | | | | | | | Many backend components don't have access to the compiler instance holding the settings. Before this change, individual settings required in these parts of the backend were made available as members of trait BTypes, implemented in the subclass BTypesFromSymbols (which has access to global). This change exposes a single value of type ScalaSettings in the super trait BTypes, which gives access to all compiler settings.
* Eliminate unreachable code before inlining a methodLukas Rytz2015-04-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Running an ASM analyzer returns null frames for unreachable instructions in the analyzed method. The inliner (and other components of the optimizer) require unreachable code to be eliminated to avoid null frames. Before this change, unreachable code was eliminated before building the call graph, but not again before inlining: the inliner assumed that methods in the call graph have no unreachable code. This invariant can break when inlining a method. Example: def f = throw e def g = f; println() When building the call graph, both f and g contain no unreachable code. After inlining f, the println() call becomes unreachable. This breaks the inliner's assumption if it tries to inline a call to g. This change intruduces a cache to remember methods that have no unreachable code. This allows invoking DCE every time no dead code is required, and bail out fast. This also simplifies following the control flow in the optimizer (call DCE whenever no dead code is required).
* Command-line flag to control inlining heuristicsLukas Rytz2015-03-311-0/+2
| | | | | Introduces a stress-test mode "everything" in which the inliner tries to inline every calliste that can be statically resolved.
* Issue inliner warnings for callsites that cannot be inlinedLukas Rytz2015-03-111-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue precise warnings when the inliner fails to inline or analyze a callsite. Inline failures may have various causes, for example because some class cannot be found on the classpath when building the call graph. So we need to store problems that happen early in the optimizer (when building the necessary data structures, call graph, ClassBTypes) to be able to report them later in case the inliner accesses the related data. We use Either to store these warning messages. The commit introduces an implicit class `RightBiasedEither` to make Either easier to use for error propagation. This would be subsumed by a biased either in the standard library (or could use a Validation). The `info` of each ClassBType is now an Either. There are two cases where the info is not available: - The type info should be parsed from a classfile, but the class cannot be found on the classpath - SI-9111, the type of a Java source originating class symbol cannot be completed This means that the operations on ClassBType that query the info now return an Either, too. Each Callsite in the call graph now stores the source position of the call instruction. Since the call graph is built after code generation, we build a map from invocation nodes to positions during code gen and query it when building the call graph. The new inliner can report a large number of precise warnings when a callsite cannot be inlined, or if the inlining metadata cannot be computed precisely, for example due to a missing classfile. The new -Yopt-warnings multi-choice option allows configuring inliner warnings. By default (no option provided), a one-line summary is issued in case there were callsites annotated @inline that could not be inlined.
* Limit the size of the ByteCodeRepository cacheLukas Rytz2015-03-111-1/+2
| | | | | I observed cases (eg Scaladoc tests) where we end up with 17k+ ClassNodes, which makes 500 MB.
* Inline final methods defined in traitsLukas Rytz2015-03-111-94/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to inline a final trait method, callsites of such methods are first re-written from interface calls to static calls of the trait's implementation class. Then inlining proceeds as ususal. One problem that came up during development was that mixin methods are added to class symbols only for classes being compiled, but not for others. In order to inline a mixin method, we need the InlineInfo, which so far was built using the class (and method) symbols. So we had a problem with separate compilation. Looking up the symbol from a given classfile name was already known to be brittle (it's also one of the weak points of the current inliner), so we changed the strategy. Now the InlineInfo for every class is encoded in a new classfile attribute. This classfile attribute is relatively small, because all strings it references (class internal names, method names, method descriptors) would exist anyway in the constant pool, so it just adds a few references. When building the InlineInfo for a class symbol, we only look at the symbol properties for symbols being compiled in the current run. For unpickled symbols, we build the InlineInfo by reading the classfile attribute. This change also adds delambdafy:method classes to currentRun.symSource. Otherwise, currentRun.compiles(lambdaClass) is false.
* Workaround for SI-9111Lukas Rytz2015-03-111-14/+55
| | | | | | | | | The inliner forces some method symbols to complete that would not be completed otherwise. This triggers SI-9111, in which the completer of a valid Java method definition reports an error in mixed compilation. The workaround disables error reporting while completing lazy method and class symbols in the backend.
* Looking up the ClassNode for an InternalName returns an OptionLukas Rytz2015-03-111-1/+1
| | | | | | | The `ByteCodeRepository.classNode(InternalName)` method now returns an option. Concretely, in mixed compilation, the compiler does not create a ClassNode for Java classes, and they may not exist on the classpath either.
* Build a call graph for inlining decisionsLukas Rytz2015-03-111-15/+188
| | | | | | | | | | Inlining decisions will be taken by analyzing the ASM bytecode. This commit adds tools to build a call graph representation that can be used for these decisions. The call graph is currently built by considering method descriptors of callsite instructions. It will become more precise by using data flow analyses.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-15 15:16:20 +0000