Repeated exception in tdsi

[GoogleCodeExporter]

D:\Code\qtrack>tdsi -i 1.swf -o 2.swf
[INFO] Apparat -- http://apparat.googlecode.com/
[INFO] Launching tool: Turbo Diesel Sport Injection
[INFO] Cpool rebuild required.
<function0>: caught java.lang.AssertionError: assertion failed
java.lang.AssertionError: assertion failed
        at scala.Predef$.assert(Predef.scala:77)
        at apparat.abc.AbcOutputStream.writeU08(AbcOutputStream.scala:85)
        at apparat.bytecode.BytecodeEncoder$.u08$1(BytecodeEncoder.scala:36)
        at apparat.bytecode.BytecodeEncoder$.writeOp$1(BytecodeEncoder.scala:103)
        at apparat.bytecode.BytecodeEncoder$$anonfun$apply$2.apply(BytecodeEncoder.scala:201)
        at apparat.bytecode.BytecodeEncoder$$anonfun$apply$2.apply(BytecodeEncoder.scala:201)
        at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
        at scala.collection.immutable.List.foreach(List.scala:45)
        at apparat.bytecode.BytecodeEncoder$.apply(BytecodeEncoder.scala:201)
        at apparat.bytecode.Bytecode.storeIn(Bytecode.scala:49)
        at apparat.abc.Abc$$anonfun$5$$anonfun$apply$2.apply(Abc.scala:155)
        at apparat.abc.Abc$$anonfun$5$$anonfun$apply$2.apply(Abc.scala:155)
        at scala.actors.Futures$$anonfun$1.apply(Future.scala:128)
        at scala.actors.Futures$$anonfun$1.apply(Future.scala:128)
        at scala.actors.FutureActor$$anonfun$act$1.apply(Future.scala:94)
        at scala.actors.FutureActor$$anonfun$act$1.apply(Future.scala:94)
        at scala.actors.Reactor$class.seq(Reactor.scala:280)
        at scala.actors.FutureActor.seq(Future.scala:56)
        at scala.actors.Reactor$$anon$3.andThen(Reactor.scala:258)
        at scala.actors.FutureActor.act(Future.scala:95)
        at scala.actors.Reactor$$anonfun$dostart$1.apply(Reactor.scala:222)
        at scala.actors.Reactor$$anonfun$dostart$1.apply(Reactor.scala:222)
        at scala.actors.ReactorTask.run(ReactorTask.scala:36)
        at scala.concurrent.forkjoin.ForkJoinPool$AdaptedRunnable.exec(ForkJoinPool.java:611)
        at scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:422)
        at scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:340)
        at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:325)
Terminate batch job (Y/N)? y

attached swf with a problem

Original issue reported on code.google.com by makc.the...@gmail.com on 10 Dec 2010 at 2:06

Attachments:

• 1.swf

[GoogleCodeExporter]

Maybe due to inlining we have more than 255 register used and the debug 
operation is expecting a register code only on 8 bits (255) so the compiler 
throw an error when the register overflow.

Joa maybe we can emit a warning for the debug operation if the register 
overflow and continue anyway.

Patrick.

Original comment by leclech.patrick on 11 Dec 2010 at 6:45

[GoogleCodeExporter]

Probably the best way to handle this. But maybe also throw a warning that 
significant register thrashing happens.

Original comment by joaebert on 11 Dec 2010 at 7:05

• Changed state: Accepted

[GoogleCodeExporter]

Anyone care to comment what does it mean in terms of not-so-1337 programmers? 
:) Does it mean that I can't debug "over-inlined" code?

Original comment by makc.the...@gmail.com on 11 Dec 2010 at 8:55

[GoogleCodeExporter]

You should see that inlining creates a lot of registers (local variables). This 
can cause a severe performance decrease. You should carefully see if this 
method is still faster.

It will contain a lot of memory and the JIT has to do a lot of work on such a 
method. Inlining is no holy grail and can cause even performance problems.

What happened to your code? Imagine writing "var i0: int = 0, var i1: int = 0, 
... var i256: int = 0". The Flash bytecode and probably the debug player can 
handle only up to 255 of those local variables. During inlining you created 
more than 255. In that case I can imagine your method got really huge which 
would be less optimal for performance.

Inlining us usually performed on rather small methods and pieces of code that 
you call/use very often.

Original comment by joaebert on 11 Dec 2010 at 9:00

[GoogleCodeExporter]

well, in this case it's solving polynomial, and it does need to be run often. 
can there be some method to instruct inliner to re-use certain variables it 
creates?

Original comment by makc.the...@gmail.com on 11 Dec 2010 at 9:27

[GoogleCodeExporter]

(actually, inlined.Macro worked much better in this particular case, I'm just 
asking for general considerations)

Original comment by makc.the...@gmail.com on 11 Dec 2010 at 9:29

[GoogleCodeExporter]

The Apparat inline expansion is rather stupid and was just implemented due to 
public demand. It is working on a very bare-bones representation of the Flash 
bytecode which means we cannot perform sophisticated analysis without a big 
hassle. That is why, for now, we will not do that.

Original comment by joaebert on 11 Dec 2010 at 9:33

[GoogleCodeExporter]

In fact Macro expansion is there to mitigate this issue since no registers are 
created and less overhead (none) exists.

Original comment by joaebert on 11 Dec 2010 at 9:34

[GoogleCodeExporter]

Original comment by joaebert on 20 Dec 2010 at 9:24

[GoogleCodeExporter]

Original comment by joaebert on 1 Feb 2011 at 7:00

• Changed state: Fixed