Re: C++ in jemalloc

On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote:
>  Hi all,
> 
> The jemalloc developers have wanted to start using C++ for a while, to
> enable some targeted refactorings of code we have trouble maintaining due
> to brittleness or complexity (e.g. moving thousand line macro definitions
> to templates, changing the build->extract symbols->rebuild mangling scheme
> for internal symbols to one using C++ namespaces). We'd been holding off
> because we thought that FreeBSD base all had to compile on GCC 4.2, in
> order to support some esoteric architectures[1].
> 
> The other day though, I noticed that there is some C++ shipping with
> FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING
> document that C++11 is a minimum for FreeBSD 11). This, combined with the
> fact that ports now points to a modern gcc, makes me think we were
> incorrect, and can turn on C++ without breaking FreeBSD builds.
Note that these are just usermode utilities, which implementation language
is not too important.  If we considered ghc or rustc to be acceptable
dependency for utilities, then they could be implemented in Haskell or
Rust as well.

> 
> Am I right? Will anything break if jemalloc needs a C++ compiler to build?
> We will of course not use exceptions, RTTI, global constructors, the C++
> stdlib, or anything else that might affect C source or link compatibility.
I wonder how can you guarantee that for current and future compilers without
having the standard saying and compiler facilities to ensure that.  See below.

> 
> Thanks,
> David (on behalf of the jemalloc developers
> 
> [1] That being said, we don't compile or test on those architectures, and
> so probably don't work there in the first place if I'm being honest. But
> we'd also like to avoid making that a permanent state of affairs that can't
> be changed.

On Thu, Oct 05, 2017 at 04:50:32PM -0700, David Goldblatt wrote:
> We can avoid it in the short term without a ton of pain. In the long run it
> would be nice to have, but I wouldn't want to tie our release schedule to
> FreeBSD's too tightly (our CI is improving to the point where the tip of
> the dev branch gets tested about as well as releases would be, so we're
> trying to de-emphasize release vs. non-release versions). Do you have a
> sense of when the situation might change (if only so I know when to check
> back)?
> 
> Thanks for the replies on this, they've been super helpful.
I do not think so.

You are talking about importing C++ code into libc.  Libc _implements_
C runtime, which is a dependency of any C++ runtime.  That is, we
cannot allow C++ runtime to be dragged into libc.

C++ freestanding implementation, by the standard, is required to provide
the runtime typeinfo, exceptions, intialization and termination support
(i.e. atexit/cxa_atexit and most important cxa_thread_atexit, if you
use TLS) and so on.  It clearly gives the cycle in the dependencies.
There is no requirement on the compilers to not use these features
in unexpected ways, and looking at the current compiler evolution, I do
expect that these features would bite us simply because we allowed C++
code in libc.

We already have some issues die to the jemalloc reliance on pthreads,
which makes the bootstraping a problem. We have to maintain the ugly
fake init trick to postpone malloc for the mutexes backing store
inside libthr to allow jemalloc to initialize without causing cyclic
dependencies.

Also, our C runtime (rtld/libc/libthr and perhaps libm) is currently
only requires C compiler (and assembler and linker) to compile. Having
C++ requirement for compilation, assuming the runtime issues I noted
above are somewhat avoided, is also not a move I consider useful.

Summary is that, in my opinion, requiring C++ compiler and working runtime
for malloc(3) implementation is not desirable.  If this goes in, low-level
parts of the libc and whole libthr must grow private malloc implementation
to not depend on libc malloc.  Currently only rtld has private malloc
(for similar reasons).