AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 27 Pull Requests Releases Wiki Activity

[*] Update this section of the read me

Browse Source
This commit is contained in:
Reece Wilson 2024-04-20 02:49:02 +01:00
parent e7d9df3cab
commit 55c352c08e
1 changed files with 9 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
README.md
View File

@ -327,57 +327,27 @@ envrionment variables, OS specific interfaces, or the overload mechanism.
### Allocator
Objects are allocated across API/module boundaries using an ABI defined by Aurora Runtime.
Such OOP design in contrast to header-everything is contingent on well-defined interface boundaries which make sense from a
perspective of optimizaton (primarily allocation and indirect branching) and usability.
Allocations are optimized by using a known good third party library, mimalloc. In the future, it should be possible to replace the
standard allocator; however, for now all allocations are routed through Aurora::Memory which is backed by mi_xxxx calls.
Mimalloc and/or other such slab and zone based allocators can and must be explored as an optimization for C++'s tendency to
arbitrary allocate memory. This should improve the performance of reasonbly written modules with OOP in mind.
Indirect branches are optimized by simply trying to design APIs that arent complete ass for humans and systems to work with.
Aurora Runtime (would like to) provide its' own global allocator to best manage resources under one best-fit allocator.
If the runtime is built with AuroraAlloc.cpp, every module that touches our shared pointers must also be built alongside
AuroraAlloc.cpp. The AuList<T>, AuHashMap<K,V>, AuBST<K,V>, and AuString types are hardened against such global allocator
conflicts; however, shared pointers are currently dependent on a control block allocated from an unspecified allocator.
### Memory Heap
Aurora provides a heap allocator for dividing up a large preallocated region of memory.
Currently, we use a modified version of O(1) heap that provides a constant worst case allocation and deallocation
of any given request. Memory is provided by AuProcess for the requested allocation, but AuMemory might be unfortunately
hit during the initialization of a heap.
of any given request.
### Shared Pointers
Memory objects, including shared pointers, and the object allocation model is defined by AuROXTL. The `AuSPtr` class template
Heap objects, including shared pointers, and the object allocation model is defined by AuROXTL. The `AuSPtr` class template
is backed by the standard `std::shared_ptr`, extended by `#include <auROXTL/auMemoryModel.hpp>,` in the default configuration.
The reason we wrap shared pointers is two folds
1) in code that doesn't need to be fast, we can simply hack in is valid checks on assignment or use an interface with panic branches
to handle null access conditions.
2) in the future, it may be desirable to use established AuEnableSharedOnThis, AuSharedFromThis, etc idoms to migrate existing code
to an alternative non-std::shared_ptr backed system.
AuSPtr<T>s allow for stage/debug build null checking to prevent hard crashing during debugging and QA.
AuSPtr and friends are reducable and constructible from and from their std::shared_ptr/unique counterparts.
```
Types:
AuSPtr<Type_t>
AuWPtr<Type_t>
AuUPtr<Type_t, Deleter_t>
Functions:
AuSPtr<T> AuMakeShared<T>(Args&& ...)
AuSPtr<T> AuUnsafeRaiiToShared<T>(T *)
AuSPtr<T> AuUnsafeRaiiToShared<T>(AuUPtr<T>)
Macros:
_new (pseudo no-throw new operator)
AuSPtr<This_T> AuSharedFromThis()
AuWPtr<This_T> AuWeakFromThis()
AuFunction<...> AuBindThis(This_t *::?, ...)
```
Temp AuSPtr<T>s can be crafted with AuUnsafeRaiiToShared from unique pointers and raw pointers so that C-like applications can
access a subset of the API.
Defer to [auROXTL](https://git.reece.sx/AuroraSupport/auROXTL) for more information