| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this commit is to allow the new inliner (in GenBCode,
coming soon) to inline methods generated by the GenASM backend of
2.11.6.
The ScalaInlineInfo attribute is added to every classfile generated
by GenASM. It contains metadata about the class and its methods that
will be used by the new inliner.
Storing this metadata to the classfile prevents the need to look up a
class symbol for a certain class file name, a process that is known to
be brittle due to name mangling. Also, some symbols are not exactly
the same when originating in a class being compiled or an unpickled
one. For example, method symbols for mixed-in members are only added
to classes being compiled.
The classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool. It just adds a few references
and bits for each method in the classfile.
Jar sizes before:
480142 scala-actors.jar
15531408 scala-compiler.jar
5543249 scala-library.jar
4663078 scala-reflect.jar
785953 scalap.jar
After:
490491 scala-actors.jar (102.1%)
15865500 scala-compiler.jar (102.1%)
5722504 scala-library.jar (103.2%)
4788370 scala-reflect.jar (102.7%)
805890 scalap.jar (102.5%)
|
| |
|
|
| |
This makes it pass under -Ybackend:GenBCode
|
|
|
Looks like the transformation did never happen because the pattern
failed to match. Why did the pattern fail to match? Because the
Symbol.apply we see in the tree claims to be a method while
Symbol_apply defined in Definitions wants to be a value.
This issue was caused because nonPrivateMember starts spitting out
overloaded symbols after erasure.
This issue has been fixed in the earlier commit, so what happens in
this commit is adding tests and fixing documentation.
|
