src: refacor MallocedBuffer to it's usage scope

[refack]

As discussed in #23543 (review).
MallocedBuffer is an unknown quantity as compared to std::unique_ptr.

1. MallocedBuffer is a new utility and is node specific, so it's semantics are not clear to me, so I assume to others as well.
   • It's maturity is unknown (Ref: src: fix bug in MallocedBuffer #23434)
   • It's ambiguous if MallocedBuffer::size is in units of T or number of byte
2. std::unique_ptr is free of runtime cost (except for its dtor), while MallocedBuffer at minimum carries the runtime cost of construction, and the memory cost of MallocedBuffer::size.
3. And probably most important to me - readability. std::unique_ptr is standardized and well documented. MallocedBuffer is only documented by its code.
4. While refactoring is seems like it has no unit test coverage.

Ref: #23543 (review)
Ref: #23434

CI: https://ci.nodejs.org/job/node-test-pull-request/1​78​21

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

@refack build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1230/pipeline

[joyeecheung]

I am not sure about arguing that std::unique_ptr as a standardized type is more readable than MallocedBuffer. The scope of MallocedBuffer is very well explained in the one-line comment:

// Simple RAII wrapper for contiguous data that uses malloc()/free().

Whereas with std::unique_ptr you don't get any answer about

1. Is it wrapping a pointer that needs to be freed or deleted? (You may get the answer by looking at the template parameter, but first you need to see the parameter explicitly spelled somewhere, which means you need to spell std::unique_ptr<something, i_use_free>)
2. Is it pointing to a contiguous chunk of memory, or an end of some other data structure?

[addaleax]

1. MallocedBuffer is a new utility and is node specific, so it's semantics are not clear to me, so I assume to others as well.

As @joyeecheung said, the semantics are defined right next to the class.

It's maturity is unknown (Ref: #23434)

I don’t think that bug lets you make conclusions about “maturity” – this is not a full-featured memory manager, this is a small utility class.

2. std::unique_ptr is free of runtime cost (except for the dtor), while MallocedBuffer is unknown at minimum carries the runtime cost of construction, and the memory cost of MallocedBuffer::size.

There’s no reason to believe that there is any difference in runtime cost. The memory cost of extra 8 bytes is negligible, and is actually useful a lot of the time.

---

I don’t think comparing to std::unique_ptr makes sense in the first place.

This structure always represents a continuous array of data. It’s closest STL equivalent is std::vector, not std::unique_ptr. Sometimes, we need to use malloc(), though (because we can actually handle allocation failures, because we convert it to a Buffer, etc.), and writing custom STL allocators is painful and adds a lot more complexity than just using MallocedBuffer().

[addaleax]

-1, see above.

[refack]

I am not sure about arguing that std::unique_ptr as a standardized type is more readable than MallocedBuffer. The scope of MallocedBuffer is very well explained in the one-line comment:

I am not sure about arguing that std::unique_ptr as a standardized type is more readable than MallocedBuffer. The scope of MallocedBuffer is very well explained in the one-line comment:

// Simple RAII wrapper for contiguous data that uses malloc()/free().

Whereas with std::unique_ptr you don't get any answer about

1. Is it wrapping a pointer that needs to be freed or deleted? (You may get the answer by looking at the template parameter, but first you need to see the parameter explicitly spelled somewhere, which means you need to spell std::unique_ptr<something, i_use_free>)
2. Is it pointing to a contiguous chunk of memory, or an end of some other data structure?

It might be my perspective, but https://en.cppreference.com/w/cpp/memory/unique_ptr seems to answer these quastion, and leave much less ambiguity.

[refack]

I don’t think comparing to std::unique_ptr makes sense in the first place.

This structure always represents a continuous array of data. It’s closest STL equivalent is std::vector, not std::unique_ptr. Sometimes, we need to use malloc(), though (because we can actually handle allocation failures, because we convert it to a Buffer, etc.), and writing custom STL allocators is painful and adds a lot more complexity than just using MallocedBuffer().

As I see it (again this might point to ambiguity) MallocedBuffer is a: Simple RAII wrapper for contiguous data that uses malloc()/free(). So the analogy to std::unique_ptr is not too far fetched (and is exemplified in #23543).

I think that the main difference between this and std::vector is that vector by design hides memory management, while MallocedBuffer put it front and center.

[addaleax]

I think that the main difference between this and std::vector is that vector by design hides memory management, while MallocedBuffer put it front and center.

Yes. So let’s use it when it matters that we use a specific memory allocator.

[refack]

I think that the main difference between this and std::vector is that vector by design hides memory management, while MallocedBuffer put it front and center.

Yes. So let’s use it when it matters that we use a specific memory allocator.

I agree that it makes sense to abstract that, I just disagree on the implementation. IMHO we should minimize our own code. Something like:

template<typename T>
struct Free {
  void operator()(T* ptr) const { free(ptr); }
};

// Specialization of std::unique_ptr that used Malloc<t>
template<typename T>
using malloced_unique_ptr = std::unique_ptr<T, Free<T>>;

template<typename T>
malloced_unique_ptr make_malloced_unique(size_t number_of_t) {
  return malloced_unique_ptr(Malloc<T>(number_of_t));
}

[addaleax]

@refack I think the main downside to that is that it does not provide size explicitly.

I just disagree on the implementation.

This PR seems to do a lot more than changing the implementation.

[refack]

@refack I think the main downside to that is that it does not provide size explicitly.

As I see it we have two use cases:

1. A "buffer" where we want to keep track of its size, store or keep track in a wider scope. There MallocedBuffer is probably a better fit.
2. An RAII wrapper for Malloc, where size is tracked independently, and probably has a release() in scope. That's where IMHO MallocedBuffer is not the best abstraction.

[refack]

This PR seems to do a lot more than changing the implementation.

Ok, so an alternative suggested at #23642

[joyeecheung]

It might be my perspective, but https://en.cppreference.com/w/cpp/memory/unique_ptr seems to answer these quastion, and leave much less ambiguity.

@refack That is a long document which just explains std::unique_ptr, can you point out how it answer those questions?

Maybe I wasn't being clear: std::unique_ptr may be able to provide the means to answer questions about the nature of the underlying pointer through template parameters, but that doesn't mean it's readable and easy to use, and the answers ultimately come from the users, not the std::unique_ptr type itself, whereas MallocedBuffer only does one job and the name iis expressive enough.

(Also, I think it's even possible to implement MallocedBuffer on top of unique_ptr and I think there is still value doing it that instead of just using unique_ptr)

EDIT: oh, yeah there is a (sort-of) implementation #23641 (comment) already

[refack]

Abandoned