Feat/TLSFAlloc

[mchalupiak]

Integration of TLSF allocator

[Pistonight]

Licesne file(s) need to be updated

[Pistonight]

do we still need this header if it's just a single define?

[Pistonight]

Why does this need to be implemented?

[Pistonight]

Why are we not unlocking? consider making a Scope lock wrapper

[Pistonight]

I think it will be slightly simpler to initialize the pool as part of the lib init then you don't need to track if it's initialized

[Pistonight]

static-initialized memory in rust can't allocate so this will not get called before initialization

[Pistonight]

it's best to not expose tlsf.h, which is implementation detail

[mchalupiak]

This is exposed so that allocator can be initialized in init.cpp (without it the type pool_t and the function tlsf_create_with_pool are undefined). Is there a better approach to achieving this? I thought the header was appropriate because BSS_ALLOC_SIZE should only be defined in one place.

[Pistonight]

// __internal/alloc.h

namespace megaton::alloc {
void init_pool();
}

// alloc.cpp

static YOUR_GLOBAL_VARIABLES_HERE;
namespace megaton::alloc {
void init_pool() {
    allocator = tlsf_create_with_pool(..);
}
}

// init.cpp
void __megaton_librs_init() {
        megaton::alloc::init_pool();
}

If you imagine alloc.cpp and init.cpp as 2 classes, allocator is like a private field that should not be exposed, but it can be initialized via a public interface (a function)

[Pistonight]

You can declare a megaton::alloc::init_pool in alloc.h then implementation detail will not be exposed (i.e. you don't need tlsf.h here or any of the extern symbols)

[Pistonight]

Why does these need to be implemented? they should already be defined in the SDK

[Pistonight]

The nn::os::Mutex implementation should be removed, you should only need the header

[mchalupiak]

I take no issue with removing the nn::os::Mutex, but it was added as a result of an undefined symbol error we had encountered previously, specifically _ZN2nn2os5MutexD1Ev was not defined. The same is true of nn::os::Mutex::{lock,unlock}, as the undefined symbols _ZN2nn2os5Mutex6unlockEv and _ZN2nn2os5Mutex4lockEv are generated. I have confirmed that these errors still appear as well

[mchalupiak]

Additionally, should the init_allocator function be thread safe? In theory it should be called at init from a single threaded context so thread safety shouldn't be an issue

[Pistonight]

Ok I remember the dtor issue.. maybe try using std::mutex?
As for lock and unlock, they aren't in the symbols so not sure why it's in nnheades, maybe it was added in a later version