The fourth iteration of rebis-dev is out

[mthom]

It contains some long promised changes on the road to garbage
collection. The two most significant are:

• partial strings are now stored in the heap and never in the atom
  table, and,

• heap reallocation failures should now be signaled to the top level
  as resource errors instead of Rust's default strategy of crashing the
  runtime by panicking.

Loading is slower as a result of these changes but other benchmarks (for example, clpz sudoku) appear to perform just as well as on master. I've done benchmarking in perf over the past day and see that page faults are much higher now. The heap now uses a bit vector
(pstr_vec) to track locations of partial strings in the heap. It's written to whenever the heap is, so it's probably (ugh) at fault.

I'd like to close the performance gap before this iteration of rebis-dev is merged to the master branch, so at some point I may try to stitch the segments of pstr_vec into the pages of heap memory they index. I thought I'd also put it to the community to do their own performance analysis and submit their findings publicly.

Many other changes accompany the two main ones:

• the functor! macro was rewritten to be more declarative at the expense of requiring visually but not technically superfluous parentheses in some of its arguments; see the tests of functor_macro.rs for usage examples
• the PStrOffset, CStr, and PStr cell tags are gone, replaced by PStrLoc; much of the partial string API implementation has been simplified; the Char tag has also been removed, see the below comment about inlined atoms. PStrLoc values index to the byte, all other reference cells index to the cell (cell_index! and heap_index! macros are used to capture these)
• the Literal and Term types have been removed; everything is done in terms of HeapCellValue now, from lexing & parsing to compilation
• the custom Heap type is introduced to host partial strings alongside the classical WAM HeapCellValue cells in the same block of memory. The pstr_vec BitVec is used to distinguish string data from cell data when needed.
• Heap uses the reserve / write_with convention to avoid overuse of the Result mechanism around heap reallocation error checking. It dispenses with bounds checking under the assumption the user reserved the required heap space already
• atoms of 6 bytes or fewer are now "inlined" meaning their byte representation is written directly into the host HeapCellValue without interacting with the atom table (this includes what were previously Char tagged cells); MAX_ARITY is reduced to 255 from 1023 to accommodate this
• some bugs in disjuncts.rs responsible for writing StackVar cells to the heap were discovered and fixed, disjuncts.rs and adjacent modules were made a little safer in response
• other miscellaneous intermediary data types were variously consolidated/removed

Of course, some components, like lib_machine.rs and parsed_results.rs, had to be re-written slightly to allow Term and Literal to no longer exist. I think I successfully captured the intent of the pre-rebis code but do let me know if I am wrong about that, and likewise with atom_table.rs or any other change I made to code I didn't originally write. @bakaq @lucksus @Skgland

I'll present these changes in greater depth in a talk held at the 2024 Scryer Prolog Meetup in Vienna in November. Talk slides will be posted here after the meetup is over.

[triska]

Congratulations Mark, and thank you!

This can be regarded as the true start of serious Scryer Prolog development: Thanks to memory reclamation on backtracking which is a consequence of heap allocation, and also due to raising resource errors instead of crashing, the system can now be used to test itself exhaustively, running arbitrarily long. This allows test cases that were previously not possible, and this will finally find all issues that arise so rarely that only systematic exhaustive search can reliably find them.

[UWN]

#1714

[triska]

It seems #1714 is now resolved with rebis-dev?

[UWN]

atoms of 6 bytes or fewer are now "inlined" meaning their byte representation is written directly into the host HeapCellValue without interacting with the atom table (this includes what were previously Char tagged cells); MAX_ARITY is reduced to 255 from 1023 to accommodate this

Is this a useful tradeoff? The 255 limit for max_arity is really a pain where one has to program around it (in, e.g. SICStus). This is so 1980s. At best. That is, a lot of extra visible Prolog code has to be written. A value unbounded would be much better. Internally, the directly encoded compounds could go up to an even smaller value, and for the very big ones, the extra space for representing the arity does not matter.

Also from a testing perspective, it is quite costly (= less chance to find errors) to test what happens when there are strings of length 6 and 7. Is there any program that makes use of this?