Implemented erlang:bump_reductions nif.

[FKubisSWM]

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[pguyot]

Thank you for this!

I wonder if we could take the opposite direction. In AtomVM, the reduction count is decremented and not incremented as on BEAM (or at least as bump_reductions/1 and process_info/2 process it). The first function could decrement the internal reduction count while the second could return the max - the current value. What do you think?

[pguyot]

This is going to slow us down as opposed to keeping the value in a local variable.

[FKubisSWM]

Local variable from opcodesswitch is unobtainable in nif. Also every context should have its own reductions counter if we want the reductions to work exactly like the OTP version.

[bettio]

I agree with @pguyot, this change is going to slow down the interpreter.

I suggest to stub this nif (and leaving a TODO) and to implement in a more efficient way this later.
Also, in general might be useful to allow some expensive NIFs to burn more than just one reduction (or maybe to restore them).

However the only information I found about this function is:

This BIF can be removed in a future version of the Beam machine without prior warning. It is unlikely to be implemented in other Erlang implementations.
Here: https://www.erlang.org/docs/19/man/erlang#bump_reductions-1

[FKubisSWM]

I agree with @pguyot, this change is going to slow down the interpreter.

I suggest to stub this nif (and leaving a TODO) and to implement in a more efficient way this later. Also, in general might be useful to allow some expensive NIFs to burn more than just one reduction (or maybe to restore them).

However the only information I found about this function is:

This BIF can be removed in a future version of the Beam machine without prior warning. It is unlikely to be implemented in other Erlang implementations.
Here: https://www.erlang.org/docs/19/man/erlang#bump_reductions-1

So should I leave only a TODO comment (in erlang.erl) or should I make some dummy implementation like for example:

-spec bump_reductions(pos_integer()) -> true.
bump_reductions(Reductions) when is_integer(Reductions), Reductions >= 1 ->
    bump_reductions(Reductions-1);
bump_reductions(0) ->
    true.

[FKubisSWM]

Also, we need the bump_reductions function for context switching testing purposes.

[jgonet]

Also, we need the bump_reductions function for context switching testing purposes.

To expand on that: I thought I used it somewhere in ETS for testing but I can't find a reference to that.
The more important thing is that prim_eval (used in erl_eval) uses it. I think we can go with a mock or we can patch it ourselves in the Popcorn since this is internal function and not part of public API.

I still think it may be useful in testing but it should be implemented in a way that doesn't slow down AtomVM in release builds.