Page MenuHomePhabricator

maniccoder (Mattias Jansson)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 7 2020, 2:24 AM (36 w, 3 d)

Recent Activity

Thu, Sep 10

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

For rpmalloc make sure to use the latest develop branch, the use of hard _exit in lld coupled with the use of fiber local storage made the allocator sometimes end up in a deadlock. It should be fixed on the develop branch.

Thu, Sep 10, 10:41 AM · Restricted Project

Aug 4 2020

maniccoder added inline comments to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.
Aug 4 2020, 10:31 PM · Restricted Project
maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

That is correct, the malloc.c is included from the rpmalloc.c file when ENABLE_OVERRIDE is set to 1, in order to correctly alias to internal functions. It should not be compiled on its own.

Aug 4 2020, 5:43 AM · Restricted Project

Jul 2 2020

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

Replacing the allocator dynamically at startup could be possible, but that's a lot of trouble. If that's we want, I could check if we can load a DLL from a TLS callback, because we need the allocator very early, before the CRT entry point is called.

Jul 2 2020, 12:29 AM · Restricted Project

Feb 3 2020

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

I'm more than happy to take a look at this use case and see what can be done to reduce the peak commit when using rpmalloc, perhaps if you file an issue on rpmalloc github project we can take it from there

Feb 3 2020, 11:00 AM · Restricted Project

Jan 11 2020

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

I think you will find that the Heap API has subpar performance since that too uses locks to ensure thread safety (unless you can guarantee that memory blocks never traverses thread boundaries).

Jan 11 2020, 4:08 AM · Restricted Project

Jan 9 2020

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

Regarding license, if you believe in public domain then rpmalloc is in public domain. If not, it's released under MIT which should be compatible with most project. If you still have issues with this, let me know and I can probably accommodate any needs you might have.

Jan 9 2020, 10:33 AM · Restricted Project

Jan 7 2020

maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

I would say it's mostly down to application usage patterns. The worst case is probably a gc-like usage where one thread does all allocation and another all deallocation, as this will cause all blocks to cross the thread cache via an atomic pointer CAS and eventually cause larger spans of blocks to traverse the thread caches via the global cache. However, even this scenario will probably be significantly faster than the standard runtime allocator.

Jan 7 2020, 6:28 AM · Restricted Project
maniccoder added a comment to D71786: [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}.

1). This also seems to improve compile time by around 5% for me. Presumably this is due to some other benefit of rpmalloc as (AFAIK) clang.exe does not use multiple threads.

Jan 7 2020, 2:36 AM · Restricted Project