behaviour tracing optimised code

For the following predicate:


foo(X) :-
        atom(X),   
        \+current_module(X),
        create_module(X, [], [eclipse_language]),
        i(X),
        compile_term(hello)@X.

i(_).

when the code is compiled optimised, then you get the following trace (in 
development branch, at least):

(optimised)
[eclipse 5]: foo(a).
  (1) 1 CALL  foo(a)   %> creep
  (1) 1 NEXT  foo(a)   %> creep
  (1) 1 NEXT  foo(a)   %> creep
  (1) 1 NEXT  foo(a)   %> creep
  .....

and the compile_term(hello) is also traced (I guess this is probably
expected?).

The NEXT ports seems to be associated with create_module/3; this is what
generates the next ports in normal compiled code, but I don't think we
should see these either.

(debuggable)
[eclipse 4]: foo(a).
  (1) 1 CALL  foo(a)   %> creep
  (2) 2 CALL  current_module(a)   %> creep
  (2) 2 FAIL  current_module(...)   %> creep
  (1) 1 ELSE  foo(a)   %> creep
  (3) 2 CALL  create_module(a, [], [eclipse_language])   %> creep
  (3) 2 NEXT  create_module(a, [], [eclipse_language])   %> creep
  (3) 2 NEXT  create_module(a, [], [eclipse_language])   %> creep
  (3) 2 NEXT  create_module(a, [], [eclipse_language])   %> creep
  (3) 2 NEXT  create_module(a, [], [eclipse_language])   %>