How is memory organized in RimStone

RimStone is a memory-safe language. A string variable is the actual pointer to a string (whether it's a text or binary). This eliminates at least one extra dereferencing and a memory read (such as the case in many other languages); it makes RimStone memory performance very close to C.

Bytes before the string constitute the ID to a memory table entry as well as the length of a string, with additional info used by memory-safety mechanisms:

"Ref count" (Reference count), stating how many RimStone variables point to string,
Status is used to describe string, such as whether it's scope is process-wide, if it's a string literal etc,
"Next free" points to the next available string block (if this one was freed too),
"Data ptr" points back to the string, which is used to speed up access.

Memory is always null-terminated, regardless of whether it's text or binary. Here's what that looks like in a picture:

Each memory block (ID+Length+string+trailing null) is a memory allocated by standard C'd memory allocation, while memory table is a continuous block that's frequently cached to produce fast access to string's properties.

RimStone performs memory-safety check only at the entrance of a statement, meaning at input and output points (if needed). The actual implementation of any RimStone statement does not use memory safety internally, because each is implemented in C as a memory safe algorithm to begin with. Because vast majority (probably close to 100%) of the functionality and computation happens inside statements (for a typical web application), the actual cost of memory safety is very small.

This is in contrast to many general purpose memory-safe languages where libraries, modules, methods etc. are implemented in the memory-safe language and the entire implementation is subject to memory-safe instrumentation and/or other methods, such as bounds checking etc. It means that inherently such languages may perform more work doing such safe-memory checks, and therefore may be slower.

Also, the length of memory allocated is stored just prior to memory (i.e. in a continuous block) and generally pre-fetched using CPU's hardware prefetching, making access to it faster than if it were part of the memory structure.

Finally, by default memory is not deallocated immediately after it's out of scope. Rather, the freeing happens when a request is complete, because the request is really the "unit" of work in a web-service based language like RimStone. This also makes final deallocation of memory faster because access to memory structure block is cached and optimized for such operation.