- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Let's blame it on the bytecodes
Fri, 2010-02-12, 11:24
Hello fellow Scala hackers and (hopefully!) avid bytecode readers!
I started a repository which contains the complete Scala library in
disassembled form. With further changes to Scala's bytecode
optimization algorithms, it may become useful to directly see the
impact of changes at the bytecode level.
This time, I used the 2.8.0-SNAPSHOT builds in the scala-tools.org
repository [1]. Maybe, I will do the same with the nightlies from the
Scala homepage as well.
To generate the disassembled files, a patched version of javap was
used. I changed javap to make the output more friendly to diffing (no
line numbers, no constant pool indices, no instruction numbering,
labels as jump targets).
You can find the repository here:
http://github.com/jrudolph/scala-library-disassembled
The branch 'tool' contains the code to generate the files.
I hope you find it useful.
Fri, 2010-02-12, 19:47
#2
Re: Let's blame it on the bytecodes
On Fri, Feb 12, 2010 at 11:24:04AM +0100, Johannes Rudolph wrote:
> To generate the disassembled files, a patched version of javap was
> used. I changed javap to make the output more friendly to diffing (no
> line numbers, no constant pool indices, no instruction numbering,
> labels as jump targets).
You have no idea how exactly this hits items on my todo list (noise-free
javap diff tool, disassembled trunk repo...) To the letter!
Part of my plan though was to build up the git history by disassembling
every revision ever, or at least the last year or so. I have every
revision built since r16000 or so, so I have the class files available.
It's a safe bet it won't fit on github at that point though.
Thanks for reading my mind,
Fri, 2010-02-12, 19:57
#3
Re: Let's blame it on the bytecodes
On Friday February 12 2010, Johannes Rudolph wrote:
> Hello fellow Scala hackers and (hopefully!) avid bytecode readers!
>
> ...
>
> To generate the disassembled files, a patched version of javap was
> used. I changed javap to make the output more friendly to diffing (no
> line numbers, no constant pool indices, no instruction numbering,
> labels as jump targets).
Is this output format one that cannot readily be created from the stock
javap output via application of the "sed" command?
> ...
Randall Schulz
Mon, 2010-02-15, 08:37
#4
Re: Let's blame it on the bytecodes
On Fri, Feb 12, 2010 at 7:40 PM, Randall R Schulz wrote:
> On Friday February 12 2010, Johannes Rudolph wrote:
>> Hello fellow Scala hackers and (hopefully!) avid bytecode readers!
>>
>> ...
>>
>> To generate the disassembled files, a patched version of javap was
>> used. I changed javap to make the output more friendly to diffing (no
>> line numbers, no constant pool indices, no instruction numbering,
>> labels as jump targets).
>
> Is this output format one that cannot readily be created from the stock
> javap output via application of the "sed" command?
Part of it, sure. However, it would be difficult to introduce
label-based jumping. Aside from that, it was for me faster to do with
the original sources around than to cook something up with sed.
That reminds me of an ongoing master thesis, an Eclipse plugin to allow not
only inspecting but also editing class files, as described below (in German)
http://www.ssw.uni-linz.ac.at/Teaching/MasterTheses/JavaBytecodePlugin/J...
I've heard about a similar plugin (CafeBabe) for IntelliJ, but I'm not
familiar with it. It would be great to know about the other alternatives for
IDE-based class-file editing.
Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner