Re: Interrupting a running jitter program

[Luca Saiu]

On 2019-11-29 at 20:24 +0100, Luca Saiu wrote:

> a) inserting a check before branches going backwards, and at the
>    beginning of every procedure.

This is my very quick experiment with a):
  http://git.ageinghacker.net/jitter/log/?h=signals

instruction branch-fast-on-signal (?f)
  code
    JITTER_BRANCH_FAST_IF_NONZERO (JITTER_SIGNAL_IS_PENDING, JITTER_ARGF0);
  end
end

P=bin/uninspired--no-threading; make -j && make -j $P && echo 'set-pending 
$loop: branch-fast-on-signal $out  b $loop  $out:' | ./scripts/emulator $P 
--print-locations --no-dry-run --cross-disassemble - --print-locations
[...]
 0.                     base: %rbx         (register)
 1.               residual 0: %r12         (register)
 2.                stack top: %r15         (register)
 3.       stack undertop ptr: %r13         (register)
 4.         handlers top ptr: %r14         (register)
 5.                      %r0: %rbp         (register)
[...]
# 0x502b70: branch-fast-on-signal/fR 0x502b80 (18 bytes):
    0x00007fafb477f514 48 8b 44 24 30           movq   0x30(%rsp),%rax
    0x00007fafb477f519 48 8b 00                 movq   (%rax),%rax
    0x00007fafb477f51c 48 83 f8 00              cmpq   $0x0,%rax
    0x00007fafb477f520 0f 85 05 00 00 00        jne    0x00007fafb477f52b
[...]

 0.                     base: $16          (register)
 1.                  scratch: $23          (register)
 2.               residual 0: $17          (register)
 3.               residual 1: $18          (register)
 4.               residual 2: $19          (register)
 5.               residual 3: $20          (register)
 6.                stack top: $22          (register)
 7.       stack undertop ptr: $21          (register)
 8.         handlers top ptr: $fp          (register)
 9.                      %r0: $10          (register)
[...]
    # 0x4637a8: branch-fast-on-signal/fR 0x4637b0 (16 bytes):
    0x7f6ff514 8fa2040c         lw      $2,1036($29)
    0x7f6ff518 8c420000         lw      $2,0($2)
    0x7f6ff51c 14400003         bnez    $2,0x7f6ff52c
    0x7f6ff520 00000000         sll     $0,$0,0x0
[...]

> I am a little worried about the performance impact of a).

set-pending probably handles the address of
jitter_signal_pending_signals incorrectly.  I think I did not export
correctly, but for this test it does not matter.

branch-fast-on-signal is *almost* as I want it.  It uses two loads
instead of one, and if this is as performance-critical as I believe it
is worth optimizing.

The solution is having a thread-local rather than global
jitter_signal_some_pending, as an element of The Array: in practice it
will be at a statically known fixed offset from (%rbx) or ($16).

This is necessary for another reason as well other than performance, and
possibly even for your simple case, José.

You already need at least two threads because of the terminal link
server.  In general a Jittery program may have multiple VM threads, each
with its own VM state.

Now, an IPC such as a signal or a message of some other kind sometimes
should be broadcast to every thread or VM state, but often it will be
directed to one specific thread or VM state: the message, and therefore
the flag holding the presence state of a message, *must* be
thread-local.

I will link all VM states in a doubly-linked list; there is already a
good data structure for that in jitter/jitter-list.h , and I will add C
functions making it easy to set the message presence state flag for
either one state, or all of them.  Even having a mutex should not be a
problem here.  The critical section is bound to state allocation and
destruction, which are infrequent operations, and already heavyweight.
Notice that sending a message is much less performance-critical than
checking for messages: sending is a one-time action; checking is
essentially polling.

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature