scala / scala-asm-legacy Goto Github PK

View Code? Open in Web Editor NEW

8.0 27.0 7.0 548 KB

A fork of asm.ow2.org for the Scala compiler

License: Other

Java 99.65% Scala 0.11% Shell 0.24%

jvm-bytecode scala-compiler jvm

scala-asm-legacy's Introduction

NO LONGER IN USE

This is a legacy repo, check https://github.com/scala/scala-asm for the current one.

A fork of ASM for the Scala Compiler

This repository contains a fork of the ASM Java bytecode manipulation and analysis framework for the Scala compiler.

The package name is changed to scala.tools.asm. There is a small number of other patches applied to the original sources. Note that this fork only contains a subset of the source files of the ASM repository.

Longer-term, we plan to retire this fork and move to stock ASM. See issue #4 for details.

Keeping in Synch

When upgrading to a new ASM release, we always import the unmodified source files and re-apply all our patches on top. This makes it easy to see how our fork differs from the official release.

Current Version

The current sources are based on the following version of ASM (browse tags here):

Version 5.1, SVN r1798, tags/ASM_5_1

Previous ASM Upgrade PR: scala/scala-asm#11

Upgrading ASM

Start by deleting all source files and copy the ones from the latest ASM release.

The original ASM sources are in an SVN repository, which is mirrored here: https://github.com/lrytz/asm-legacy-svn-clone. You can use this mirror, your own git-svn mirror, or the original SVN repository to grab the sources of a new ASM version. A description how to work with the git-svn clone is here: lrytz/asm-legacy-svn-clone#1.

Excluded Files (don't copy):

package.html files
org/objectweb/asm/commons, but keep CodeSizeEvaluator.java
org/objectweb/asm/optimizer
org/objectweb/asm/xml

Take a look at the previous PR that upgraded ASM (see above). Follow the upgrade procedure in the same way.

The re-packaging and cleanup commits can be applied using the following commands:

convert line endings (there are some CRLF)
find src -name '*.java' | xargs dos2unix
change package clauses
find src -name '*.java' | xargs sed -i '' -e 's/package org\.objectweb\.asm/package scala.tools.asm/'
update imports
find src -name '*.java' | xargs sed -i '' -e 's/import org\.objectweb\.asm/import scala.tools.asm/'
update @links, @associates
find src -name '*.java' | xargs sed -i '' -e 's/@link org\.objectweb\.asm/@link scala.tools.asm/'
find src -name '*.java' | xargs sed -i '' -e 's/@associates org\.objectweb\.asm/@associates scala.tools.asm/'
remove trailing whitespace
find src -name '*.java' | xargs sed -i '' -e 's/[ ]*$//'

Cherry-pick the actual changes that we have in our fork:

Include the commits labelled [asm-cherry-pick] in the previous upgrade PR
Include the changes to src that were added since the last upgrade, and label them [asm-cherry-pick]

Update the "Current Version" section of this README.

scala-asm-legacy's People

Contributors

Stargazers

Watchers

Forkers

lrytz xunavy kazu-zamasu danix800 pdmack bixzweb isabella232

scala-asm-legacy's Issues

Merge upstream changes from ASM 5.2, 6.0-BETA

@forax suggested that the ASM 5.2 would be worthwhile for us as it contains a few bug fixes: http://asm.ow2.org/history.html

ASM 6.0 is almost almost ready too. We might instead jump straight to that, which will give us the platform to read/write module-info.class, although we might not actually need this. It also contains the equivalent of my patch in #12.

Finally, ASM has moved to Git, so we should update (and simplify!) our process for pulling from upstream. We can either merge from the upstream tag, or create a new branch with our changes rebased on the upstream tag.

Move to stock ASM

Here's what's required to move to stock ASM

Repackage

Change org.objectweb.asm to scala.tools.asm.

Jar Jar (SO answer) - last release in 2012 though
Proguard (SO answer), with some scripting to get all class names

Get Rid of our Patches

Class CustomAttr.
- Class is in the asm package to allow accessing the byte array directly.
- Can we avoid using this class by emitting attributes differently in the backend?
Expose maxLocals / maxStack in MethodWriter.
- Should be fixed by implementing a visitor that computes those values, which will also be more efficient. See https://github.com/scala-opt/scala/issues/1.
Associate LabelNodes with their Label.
- Not sure why we need this patch, need to try out what breaks if we revert it.
- The patch seems to be not recommended, see this thread.
Allow setting stack values in analysis frames
- This might go upstream.
Multiple methods for initializing analysis values
- This might go upstream.

The more cosmetic changes can be handed upstream or dropped.

items[] size in ClassWriter is too small for large scala sources

Scala compiler is crashing with the following stacktrace https://gist.github.com/mdedetrich/069a9b506eb6b7ff01ed

This line appears to be causing the issue https://github.com/scala/scala-asm/blob/master/src/main/java/scala/tools/asm/ClassWriter.java#L611, it seems that statically setting the size of the array to 256 is too small for the size of the Scala source being analyzed

There is already an issue on this for Scalac, so I am not sure if thats a better place to manage the issue (see https://issues.scala-lang.org/browse/SI-9391)

Upgrade to ASM 6.0

Released two weeks ago, changelog: http://asm.ow2.org/history.html. "Invalid class files generated for large methods (regression introduced in 5.2)" sounds important.

Performance optimization opportunities in Analyzer

Identified by @retronym scala/scala#6075 (comment)

https://github.com/scala/scala-asm/blob/v5.1.0-scala-2/src/main/java/scala/tools/asm/tree/analysis/Frame.java#L623-L632

Type.getArgumentTypes(desc).length / Type.getReturnType(desc) == Type.VOID_TYPE could be directly implemented without constructing a Type isntance
The same can be done in the Scala compiler (https://github.com/scala/scala/blob/v2.12.3/src/compiler/scala/tools/nsc/backend/jvm/analysis/InstructionStackEffect.scala#L63-L64)

In Type.java, a number of String to char[] conversions are performed to call into getType. If this method was duplicated to operatoe on String directly, those conversions could be avoided.

public static Type getReturnType(final String methodDescriptor) {
        char[] buf = methodDescriptor.toCharArray();
        return getType(buf, methodDescriptor.indexOf(')') + 1);
    }

Could use lastIndexOf to search from the end of the descriptor.