Introducing WTF::makeUnique<T> and WTF::makeUniqueWithoutFastMallocCheck<T>

# Yusuke Suzuki (5 days ago)

Hello WebKit folks!

I would like to announce that I’ve just landed the patch which introduces WTF::makeUnique<T> and WTF::makeUniqueWithoutFastMallocCheck<T> in trac.webkit.org/changeset/248846, trac.webkit.org/changeset/248846.

They are drop-in-replacement to std::make_unique<T>, and we should not use std::make_unique<T> after that patch is introduced.

I’m planning to add cpplint check for std::make_unique to avoid the use of that.

The motivation behind this change is the following.

  1. Our typical way of allocating heap memory is three-fold. Using containers (Vector etc.), RefCounted, and std::unique_ptr.
  2. Containers and RefCounted are covered well by FastMalloc.
  3. But std::unique_ptr case, we missed using FastMalloc in many places so far.

Even in very recently written code, we missed FastMalloc annotation. For example, we sometimes create a data structure just like a struct, and allocate it with make_unique.

struct XXXData { ... };

m_data = std::make_unique<XXXData>();

We missed WTF_MAKE_STRUCT_FAST_ALLOCATED annotation in XXXData so frequently so that the allocation of XXXData ends up being allocated from system-malloc.

This WTF::makeUnique adds one static_assert over std::make_unique: the static_assert ensures T is FastMalloced or IsoHeap-allocated. Otherwise, we see compile-error. This mechanism surprisingly found so many classes that do not have WTF_MAKE_FAST_ALLOCATED / WTF_MAKE_STRUCT_FAST_ALLOCATED in our code base.

If the type T comes from ThirdParty and if we cannot annotate T with FAST_ALLOCATED, we can use WTF::makeUniqueWithoutFastMallocCheck explicitly as a fallback.

More detailed explanation behind why we took this design (instead of allocating FastMalloced-memory automatically when using makeUnique<T>() etc.) is described in ChangeLog in trac.webkit.org/changeset/248846/webkit, trac.webkit.org/changeset/248846/webkit.

I already annotated missed structs / classes with WTF_MAKE_FAST_ALLOCATED in trac.webkit.org/changeset/248762, trac.webkit.org/changeset/248762. So, now I think 99% of allocations in WebKit-itself are handled well by FastMalloc.

Contact us to advertise here
# Yusuke Suzuki (5 days ago)

Note that style-checker change is landed now.

# Antti Koivisto (a day ago)

On Mon, Aug 19, 2019 at 10:25 AM Yusuke Suzuki <ysuzuki at apple.com> wrote:

Hello WebKit folks!

I would like to announce that I’ve just landed the patch which introduces WTF::makeUnique<T> and WTF::makeUniqueWithoutFastMallocCheck<T> in trac.webkit.org/changeset/248846. They are drop-in-replacement to std::make_unique<T>, and we should not use std::make_unique<T> after that patch is introduced. I’m planning to add cpplint check for std::make_unique to avoid the use of that.

The motivation behind this change is the following.

  1. Our typical way of allocating heap memory is three-fold. Using containers (Vector etc.), RefCounted, and std::unique_ptr.
  2. Containers and RefCounted are covered well by FastMalloc.
  3. But std::unique_ptr case, we missed using FastMalloc in many places so far.

Even in very recently written code, we missed FastMalloc annotation. For example, we sometimes create a data structure just like a struct, and allocate it with make_unique.

struct XXXData { ... };

m_data = std::make_unique<XXXData>();

We missed WTF_MAKE_STRUCT_FAST_ALLOCATED annotation in XXXData so frequently so that the allocation of XXXData ends up being allocated from system-malloc.

This WTF::makeUnique adds one static_assert over std::make_unique: the static_assert ensures T is FastMalloced or IsoHeap-allocated. Otherwise, we see compile-error.

Could WTF::makeUnique simply use FastMalloc by default? We could then remove most of these messy annotations.

This would require replacing std::unique_ptr with a type that knows how to free the objects correctly (bring back OwnPtr!) but that doesn't seem like a big deal. It wouldn't play well with mixed use of OwnPtr and new/delete but that should be avoided in any case.

antti

# Darin Adler (a day ago)

On Aug 23, 2019, at 7:26 AM, Antti Koivisto <koivisto at iki.fi> wrote:

Could WTF::makeUnique simply use FastMalloc by default? We could then remove most of these messy annotations.

This would require replacing std::unique_ptr with a type that knows how to free the objects correctly (bring back OwnPtr!) but that doesn't seem like a big deal. It wouldn't play well with mixed use of OwnPtr and new/delete but that should be avoided in any case.

I also suggested this, and you can see Yusuke’s response here bugs.webkit.org/show_bug.cgi?id=200611#c18.

— Darin

# Alex Christensen (18 hours ago)

This may be a tangent, but I wouldn’t mind replacing our use of std::unique_ptr with a smart pointer with "const T get() const” and “T get()” instead of std::unique_ptr’s “T* get() const”. I think that would help us write more const-correct code.

Want more features?

Request early access to our private beta of readable email premium.