Skip to content
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

Open
anatoliykmetyuk opened this issue Apr 23, 2014 · 1 comment
Open

Strange behaviour of the debugger with SubScriptActors #22

anatoliykmetyuk opened this issue Apr 23, 2014 · 1 comment
Labels

Comments

@anatoliykmetyuk
Copy link
Collaborator

Consider following program:

  class SimpleActor extends SubScriptActor {
    def script live = {println("I exist")}
  }

  def main(args: Array[String]) {
    val as = ActorSystem()
    for (_ <- 1 to 10) as actorOf Props[SimpleActor]
  }

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.

@AndreVanDelft
Copy link
Owner

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:
(* process *) - launch a process, comparable with process& on the Unix command line.
(** anchor **) - a node onto which launched processes are anchored

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 launch on the here variable, with a script lambda as a parameter. The following expressions are equivalent:

(* process *)
{! here.launch([process]) !}

Another issue:
We should consider to let Akka run the SubScript VM. Then the VM's run method should not be called any more (once), but instead the Akka scheduler would need to call workToDo() every now and then.

anatoliykmetyuk pushed a commit to anatoliykmetyuk/subscript that referenced this issue Mar 4, 2015
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants