erts: Add BIFs processes_iterator/0 and processes_next/1

[lucioleKi]

This PR adds 2 BIFs to the erlang module.

processes_iterator/0 returns a process iterator that can be used to iterate through the process table.

process_next/1 takes in a process iterator and returns a 2-tuple, consisting of one process identifier and a new process iterator. If the process iterator runs out of processes in the process table, none will be returned.

By using these 2 BIFs instead of processes/0, one can avoid creating a potentially huge list of the pids for all existing processes, at the cost of less consistency guarantees. Process identifiers returned from consecutive calls of process_next/1 may not be a consistent snapshot of all elements existing in the table during any of the calls. The process identifier of a process that is alive before processes_iterator/0 is called and continues to be alive until processes_next/1 returns none is guaranteed to be part of the result returned from one of the calls to processes_next/1.

[github-actions]

CT Test Results

    5 files    211 suites   1h 54m 20s ⏱️
3 161 tests 2 872 ✅ 289 💤 0 ❌
4 151 runs  3 790 ✅ 361 💤 0 ❌

Results for commit 69f7884.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[rickard-green]

Overall it looks good, but I have a few comments.

[josevalim]

This is amazing! We have spotted the process listing in erts_code_purger to be a huge cost when erasing modules, which became much more apparent once we increased the process table. Ideally we would be able to purge modules in batches to alleviate the cost, but reducing the cost of erlang:processes() will definitely be welcome. Do you think this could be used there?

[rickard-green]

Yes, the processes iterator will be used by the code purger process as well as the literal area collector process in OTP 28.

[josevalim]

@rickard-green fantastic! Do you think it would be also possible to purge batches of modules in the future too? Or is it a much more complex change? Or perhaps one that would not yield benefits?

[garazdawi]

Or is it a much more complex change?

It is a much more complex change as all parts of the VM that deals with code purging needs to be tought to handle multiple address ranges instead of just one. I'm uncertain how much work it would be, but definitely more than what is in this PR.

[rickard-green]

The most problematic part as I see it is the literal area collection (which will be done for all modules with a literal area which I suspect is most of the modules). During the collection all copying of all terms in message sends needs to be aware of the literal area being collected and make copies of literals in that area instead of passing references to the literals. As it is now with only one area collected at a time, this is relatively cheap, but having a number of areas to check against might get costly.