SuperMalloc-like implementation for Golang X86?

[Glen Newton]

I just encountered SuperMalloc[1] on HackerNews[2]. I don't know too much about such things, but it does look interesting: 

"SuperMalloc is an implementation of malloc(3) originally designed for X86 Hardware Transactional Memory (HTM). It turns out that the same design decisions also make it fast even without HTM. We compared SuperMalloc to DLmalloc, JEmalloc, Hoard, and TBBmalloc, For the malloc-test benchmark, with 1 thread SuperMalloc is about 2.1 times faster than the best alternatives, with 8 threads and HTM SuperMalloc is 2.75 times faster, and on 32 threads without HTM SuperMalloc is 3.4 times faster. SuperMalloc generally compares favorably with the other allocators on speed, scalability, speed variance, memory footprint, and code size."[3]

Is this something that might be useful for Go?

Thanks,

Glen

[1]http://dl.acm.org/authorize.cfm?key=N98611

[2]https://news.ycombinator.com/item?id=10770781

[3]http://conf.researchr.org/event/ismm-2015/ismm-2015-papers-supermalloc-a-super-fast-multithreaded-malloc-for-64-bit-machines

[Ian Lance Taylor]

On Mon, Dec 21, 2015 at 6:59 AM, Glen Newton <glen....@gmail.com> wrote:
> I just encountered SuperMalloc[1] on HackerNews[2]. I don't know too much
> about such things, but it does look interesting:
>
>> "SuperMalloc is an implementation of malloc(3) originally designed for X86
>> Hardware Transactional Memory (HTM). It turns out that the same design
>> decisions also make it fast even without HTM. We compared SuperMalloc to
>> DLmalloc, JEmalloc, Hoard, and TBBmalloc, For the malloc-test benchmark,
>> with 1 thread SuperMalloc is about 2.1 times faster than the best
>> alternatives, with 8 threads and HTM SuperMalloc is 2.75 times faster, and
>> on 32 threads without HTM SuperMalloc is 3.4 times faster. SuperMalloc
>> generally compares favorably with the other allocators on speed,
>> scalability, speed variance, memory footprint, and code size."[3]
>
>
> Is this something that might be useful for Go?

I have not looked at SuperMalloc, but I note that the main driver of
the design of the allocator in Go is support for garbage collection.
It may be possible to adopt some ideas from SuperMalloc but it's
unlikely that we can use it directly.

Ian

[Glen Newton]

Thanks.
Glen

[RogerV]

>> I have not looked at SuperMalloc, but I note that the main driver of
>> the design of the allocator in Go is support for garbage collection.
>> It may be possible to adopt some ideas from SuperMalloc but it's
>> unlikely that we can use it directly.

Because the direction of Golang 1.5 and 1.6 is to avoid going down the path of generational GC (where live objects are copied to a different generational heap area) this woould then seem to decouple GC from the memory allocator/deallocator. Any memory allocator that leaves objects in place for duration of their lifetime woiuld seem to be possibly compatible for use (as in the allocator/deallocator could then be treated as a plugin to Golang GC).

As such any allocator/dealloctor that exhibited the externally visible semantics of C runtime malloc()/free() would seem plausible. (Am I off base here?)

The first thing most people look to address in C/C++ applications that rely on malloc()/free() is to replace with one that has better behavior in respect to memory fragmentation - crucially important for long running software systems. There are nice alternatives to the stock malloc()/free(). I built one for Aldus PagerMaker in the early 90's that sped the app up 20% across the board and used memory more efficiently.

With SuperMalloc the focus shifts to transactional semantics.

[Ian Lance Taylor]

On Sat, Jan 2, 2016 at 10:38 AM, RogerV <roger....@gmail.com> wrote:
>>> I have not looked at SuperMalloc, but I note that the main driver of
>>> the design of the allocator in Go is support for garbage collection.
>>> It may be possible to adopt some ideas from SuperMalloc but it's
>>> unlikely that we can use it directly.
>
> Because the direction of Golang 1.5 and 1.6 is to avoid going down the path of generational GC (where live objects are copied to a different generational heap area) this woould then seem to decouple GC from the memory allocator/deallocator. Any memory allocator that leaves objects in place for duration of their lifetime woiuld seem to be possibly compatible for use (as in the allocator/deallocator could then be treated as a plugin to Golang GC).
>
> As such any allocator/dealloctor that exhibited the externally visible semantics of C runtime malloc()/free() would seem plausible. (Am I off base here?)

What you say is somewhat true, but it's also true that the GC needs to
look at the same data structures as the memory allocator. In
particular note that Go supports interior pointers (e.g., the address
of a field in a struct or an element in a slice), which means that the
GC needs to get from a pointer to the start of the object to which the
pointer points. That operation needs to happen in a write barrier,
and that means it needs to be as fast as possible. A memory allocator
that doesn't make that operation fast isn't going to be suitable for
Go.

Ian