runtime: migrate to an internal memory allocator

[mertcandav]

Jule Runtime: Migration to Internal Memory Allocator

This PR replaces the Jule runtime's reliance on the standard C++ new and delete operators with a custom memory allocator based on the rpmalloc allocation algorithm.

The allocator has been implemented directly in Pure Jule and integrated into the Jule runtime. It has no external dependencies and is now used by both the runtime and the API for their internal memory allocations.

Motivation

The Jule runtime previously relied on the standard C++ new and delete operators for memory allocation. While this provided a simple and familiar allocation mechanism, it limited the runtime's ability to optimize memory management for its own concurrency and execution model.

The main motivations for introducing a custom allocator are:

• Better concurrency performance: Jule places a strong emphasis on concurrency, but memory allocation was not sufficiently optimized for highly concurrent workloads.
• Greater control over memory management: The runtime had limited control over how its memory was allocated and reclaimed.
• Improved performance: The previous allocation strategy did not provide the performance characteristics desired by the runtime.

A dedicated allocator allows the runtime to manage allocations according to its own requirements rather than relying entirely on the behavior of the standard C++ allocator.

The new allocator is based on the rpmalloc allocation algorithm and has been reimplemented directly in Pure Jule.

Rather than introducing rpmalloc as an external dependency, its algorithm has been adapted and integrated into the runtime itself. This keeps the runtime self-contained while allowing the allocator to be specifically integrated with Jule's execution model.

rpmalloc was chosen as the foundation for several reasons:

• Thread caching: Its per-thread caching mechanisms fit particularly well with Jule's C:M:P concurrency model.
• High performance: rpmalloc is designed specifically for fast concurrent memory allocation and deallocation.
• No runtime dependency: The allocator can be implemented directly inside the Jule runtime without requiring an additional third-party library at runtime.
• Small and adaptable: Its relatively compact design makes it practical to port, adapt, and integrate into the runtime.

This makes rpmalloc a good foundation for an allocator that can evolve alongside Jule's runtime architecture.

Runtime and API Changes

The Jule runtime and API now use the custom allocator for their internal allocations.

The allocator is also exposed through the following C++ API:

void* __jule_malloc(size_t size);
void __jule_dealloc(void* ptr);

Both functions operate on raw memory. They do not construct or destroy C++ objects.

Object lifetime management remains the responsibility of the compiler and API where appropriate. When an allocation represents an object requiring initialization or destruction, the corresponding constructor and destructor calls are emitted or performed separately.

This separation keeps the allocator focused purely on memory management while preserving the existing object-lifetime semantics.

Standard Allocators Remain Unchanged

The new allocator does not override the standard C and C++ allocation functions by default.

In particular, it does not replace:

• malloc
• free
• new
• delete

The custom allocator is therefore isolated to allocations explicitly performed through the Jule runtime and API. Existing C++ code using the standard allocation mechanisms continues to use the standard allocators unless explicitly changed.