-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange behaviour of the debugger with SubScriptActors #22
Comments
The current SubScriptActor implementation depends on a hack in the call graph to start actor live scripts. This is highly dubious; I would certainly not trust the debugger to deal with this. Therefore I have now implemented process launching. Syntax: A launched process is anchored to the nearest anchor node. The root node of a ScriptExecutor is an anchor node, so there is always one available. It is also possble to launch processes by calling the method
Another issue: |
In Scala 2.8.2, an optimization was added to create a static cache for Symbol literals (ie, the results of `Symbol.apply("foo"))`. This saves the map lookup on the second pass through code. This actually was broken somewhere during the Scala 2.10 series, after the addition of an overloaded `apply` method to `Symbol`. The cache synthesis code was made aware of the overload and brought back to working condition recently, in scala#3149. However, this has uncovered a latent bug when the Symbol literals are defined with traits. One of the enclosed tests failed with: jvm > t8933b-run.log java.lang.IllegalAccessError: tried to access field MotherClass.symbol$1 from class MixinWithSymbol$class at MixinWithSymbol$class.symbolFromTrait(A.scala:3) at MotherClass.symbolFromTrait(Test.scala:1) This commit simply disables the optimization if we are in a trait. Alternative fixes might be: a) make the static Symbol cache field public / b) "mixin" the static symbol cache. Neither of these seem worth the effort and risk for an already fairly situational optimization. Here's how the optimization looks in a class: % cat sandbox/test.scala; qscalac sandbox/test.scala && echo ":javap C" | qscala; class C { 'a; 'b } Welcome to Scala version 2.11.5-20141106-145558-aa558dce6d (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_20). Type in expressions to have them evaluated. Type :help for more information. scala> :javap C Size 722 bytes MD5 checksum 6bb00189166917254e8d40499ee7c887 Compiled from "test.scala" public class C { public static {}; descriptor: ()V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=0, args_size=0 0: getstatic AndreVanDelft#16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$; 3: ldc AndreVanDelft#18 // String a 5: invokevirtual AndreVanDelft#22 // Method scala/Symbol$.apply:(Ljava/lang/String;)Lscala/Symbol; 8: putstatic AndreVanDelft#26 // Field symbol$1:Lscala/Symbol; 11: getstatic AndreVanDelft#16 // Field scala/Symbol$.MODULE$:Lscala/Symbol$; 14: ldc AndreVanDelft#28 // String b 16: invokevirtual AndreVanDelft#22 // Method scala/Symbol$.apply:(Ljava/lang/String;)Lscala/Symbol; 19: putstatic AndreVanDelft#31 // Field symbol$2:Lscala/Symbol; 22: return public C(); descriptor: ()V flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial AndreVanDelft#34 // Method java/lang/Object."<init>":()V 4: getstatic AndreVanDelft#26 // Field symbol$1:Lscala/Symbol; 7: pop 8: getstatic AndreVanDelft#31 // Field symbol$2:Lscala/Symbol; 11: pop 12: return } fixup
Consider following program:
Now, if you run it without a debugger (with abt run), everything happens as expected. You get 10 "I exist" messages at the console in every run.
However, if you run it with a debugger (abt debug), strange things happen.
First, even before "Step" button is clicked, there's a random amount (up to 10) of "I exist" messages at the console (this means, SubScript VM starts some processing without being blocked by the debugger).
Second, not every actor is spawned. Some InvokeFromET messages (used to dynamically and sequentially activate subscript actors templates from the main graph) are observable in the message queue (also random amount of them), but it's often the case that debugger doesn't process them, simply saying "Waiting" in the current message window when it's time to process them.
I suppose that somehow it is related to the dynamic nature of actor templates activation.
The text was updated successfully, but these errors were encountered: