Single stepping issue in the JIT

Good Evening Polo,

I am at the next problem of DebugTools and the JIT. It is a weird one
and at the boundary of my knowledge about context activation.

Interpreter:
 st> a := nil. p := [a :=3 ] newProcess
 st> p singleStep; suspend
 Process(nil at userSchedulingPriority, suspended)


JIT:
 st> a := nil. p := [a :=3] newProcess
 st> p singleStep; suspend
 Semaphore(nil: held, 0 waiting processes)

So something went wrong with the stack in the JIT case. I have a
similar issue with the >>#stepByteCode of the Debugger.

 st> deb := Debugger on: [a := 5. b := 6. c := 7] newProcess
 st> blo := [deb process singleStep; suspend]
 st> blo value
 Semaphore(nil: held, 0 waiting processes)
 st> deb process
 Process(nil at userSchedulingPriority, ready to run)

So the process does not suspend and the TOS appears to be something
wird. Do you have an idea of what could go wrong?

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, Jan 03, 2014 at 08:56:12PM +0100, Holger Hans Peter Freyther wrote:

> So the process does not suspend and the TOS appears to be something
> wird. Do you have an idea of what could go wrong?

I think it is a race:

_after_ the process has been suspended by the primitive the async queue
is ran which will put back the semaphoreOOP into the myList.

(gdb) bt
#0  0xb76d2901 in remove_process_from_list (processOOP=processOOP@entry=0x40442c68)
    at interp.c:1399
#1  0xb76d29dc in add_last_link (semaphoreOOP=0x4043f6c0,
    processOOP=processOOP@entry=0x40442c68) at interp.c:1478
#2  0xb76d2a39 in sleep_process (processOOP=processOOP@entry=0x40442c68) at interp.c:1887
#3  0xb76d73cf in resume_process (processOOP=processOOP@entry=0x40489e78,
    alwaysPreempt=<optimized out>, alwaysPreempt@entry=false) at interp.c:1797
#4  0xb76e43bf in _gst_sync_signal (semaphoreOOP=semaphoreOOP@entry=0x40489e80,
    incr_if_empty=incr_if_empty@entry=true) at interp.c:1544
#5  0xb76e4717 in _gst_do_async_signal (semaphoreOOP=0x40489e80) at interp.c:1559
#6  0xb76e58bf in empty_async_queue () at interp.c:1632
#7  _gst_interpret (processOOP=processOOP@entry=0x40489e78) at interp-jit.inl:420
#8  0xb76e6c00 in _gst_nvmsg_send (receiver=receiver@entry=0x4043c800,
    sendSelector=sendSelector@entry=0x40489e10, args=args@entry=0x0,
    sendArgs=sendArgs@entry=0) at interp.c:2317

So is it possible that the suspended process is also the get_active_process
at that time? And then it gets re-inserted into the waiting list?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 03/01/2014 21:19, Holger Hans Peter Freyther ha scritto:
Doesn't sound impossible.  I'll take a look next week (full week of free
time hacking!)

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, Jan 03, 2014 at 09:21:01PM +0100, Paolo Bonzini wrote:

> > So is it possible that the suspended process is also the get_active_process
> > at that time? And then it gets re-inserted into the waiting list?
>
> Doesn't sound impossible.  I'll take a look next week (full week of free
> time hacking!)

Yeah! We have plenty of fun stuff waiting. :)

diff --git a/libgst/prims.def b/libgst/prims.def
index 72add2b..65d4eb3 100644
--- a/libgst/prims.def
+++ b/libgst/prims.def
@@ -2873,6 +2873,8 @@ primitive VMpr_Process_suspend [succeed,check_interrupt]
 
   oop1 = STACKTOP ();
   suspend_process (oop1);
+  if (oop1 == switch_to_process)
+       printf("Suspended is switched to process.\n");
   PRIM_SUCCEEDED;
 }


 st> a := nil. p := [a := 3 ] newProcess
 nil
 Process(nil at userSchedulingPriority, suspended)
 st> p singleStep; suspend
 Suspended is switched to process.
 Semaphore(nil: held, 0 waiting processes)


So we suspend the process but it is still the process we want to switch
to. I don't know the semantics here too well. E.g. why doesn't this happen
with the interpreter and what is the right way a suspended process should
become ready-to-run again?

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, Jan 04, 2014 at 08:54:46AM +0100, Holger Hans Peter Freyther wrote:

>    oop1 = STACKTOP ();
>    suspend_process (oop1);
> +  if (oop1 == switch_to_process)
> +       printf("Suspended is switched to process.\n");
>    PRIM_SUCCEEDED;
>  }

diff --git a/libgst/interp.c b/libgst/interp.c
index 0a01361..ab67daf 100644
--- a/libgst/interp.c
+++ b/libgst/interp.c
@@ -1794,7 +1794,8 @@ resume_process (OOP processOOP,
     {
       /* We're resuming a process with a *equal or higher* priority, so sleep
          the current one and activate the new one */
-      sleep_process (activeOOP);
+      if (active->myList != _gst_nil_oop)
+        sleep_process (activeOOP);
       activate_process (processOOP);
     }
   else


this is my work-around. I have no idea if that is the right place and/if
it is correct. The idea is that an already process will not be made runnable.

The real question is probably how this code can be suspended and still be
considered as the next process.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, Jan 04, 2014 at 02:54:42PM +0100, Holger Hans Peter Freyther wrote:
> this is my work-around. I have no idea if that is the right place and/if
> it is correct. The idea is that an already process will not be made runnable.
>
> The real question is probably how this code can be suspended and still be
> considered as the next process.


>>#testCurtailFinish appears to be a true test case issue. The >>#finish
method appears to finish more than one context. I have no idea how this
could break as the jit will go through the normal context activation and
unwinding code.

It would be really great if we could go through this together next week.
With local hacks I have "make check" working for the JIT and I hope I can
enable a matrix build for travis soon and move to lightning 2.0 (and get
ARM support that way).


holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 04/01/2014 14:54, Holger Hans Peter Freyther ha scritto:
Yes, this looks like the right fix!

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk