Does neovim from this formula use jemalloc?

[kirelagin]

I see that the formula mentions jemalloc in the resources section and nowhere else. I checked neovim and I see that it uses jemalloc by default. Is neovim, therefore, expected to be built with jemalloc?

I’m asking because:

1. objdump tells me that /usr/local/bin/nvim is not dynamically linked against jemalloc.
2. jemalloc is known to be broken on 10.12 Sierra, but I observe perfectly working neovim on my laptop.

[fwalch]

You can check nvim --version. The formula links the dependencies statically.

[kirelagin]

Ok, I see now, thanks. Do you have any idea why it works then, given jemalloc/jemalloc#420?

[justinmk]

Without further information, we can't do much with this.

[kirelagin]

That’s a pretty cool reason to close the issue, given that it were you who I asked to provide information.

By the way, by a pure coincidence, I believe, I know what is going on now. nvim built from this formula does not use jemmaloc. From what I understood skimming through other formulas, the resource keyword is to be used in some very specific situations. You should have used depends_on, which would have pulled jemalloc from its brew formula, which configures prefix.

[kirelagin]

Hm. I see, you use je_ functions directly.

The formula links the dependencies statically.

If this is true, then I guess, the problem is that you are not calling register_zone() (see jemalloc/jemalloc#381).

[kirelagin]

Hm, no, that’s probably not the case. According to that issue, it should still work fine if je_malloc is called directly.

Anyway, here is what I know for sure: if I export MALLOC_CONF="prof:true,prof_prefix:jeprof.out" and run nvim it should either create that file with profiling info or barf that it does not understand these options (if jemalloc was built without debug). But nothing happens when I run neovim and I take this to mean that it is not using jemalloc.

[jszakmeister]

That’s a pretty cool reason to close the issue, given that it were you who I asked to provide information.

I'd argue there's a better place to ask questions than on the issue tracker for the Homebrew recipe. :-( At the very least, a better description of the problem you were seeing would have been nice. But all of that said, the first comment posted answered your question. :-)

Anyway, here is what I know for sure: if I export MALLOC_CONF="prof:true,prof_prefix:jeprof.out" and run nvim it should either create that file with profiling info or barf that it does not understand these options (if jemalloc was built without debug). But nothing happens when I run neovim and I take this to mean that it is not using jemalloc.

Why should it barf? If jemalloc was built without debug, wouldn't it just ignore the env variable? That would be my expectation and experience with other libraries that do similar things.

It is using jemalloc, which was recently updated, BTW: 3f4322f7e9b9451c56c0342b4011604a92cb285c

[kirelagin]

Why should it barf?

That’s what I see with neovim from nixpkgs acutally built with jemalloc:

› export MALLOC_CONF="prof:true,prof_prefix:jeprof.out"
› ./result/bin/nvim
<jemalloc>: Invalid conf pair: prof:true
<jemalloc>: Invalid conf pair: prof_prefix:jeprof.out

I'd argue there's a better place to ask questions than on the issue tracker for the Homebrew recipe.

My initial question was how it was possible that neovim worked with jemalloc when it was well known that jemalloc was broken on macOS (I still have no idea how that was possible). I truly believe that this is the best place for this kind of questions (I recall, I tried IRC before asking here, but got no response). Of course, I’m open to other suggestions.

which was recently updated, BTW: 3f4322f

Yeah, I know. I have already updated jemalloc in nixpkgs and neovim from nixpkgs works with jemalloc on macOS for me again. I don’t have to use Homebrew anymore that’s why I kind of forgot about this question.

[kirelagin]

Ah, got it. The environment variable is also prefixed: JE_MALLOC_CONF. :anguished:

Huh, now with the fixed jemalloc we will never be able to find out how it worked before. I gues, it doesn’t matter now.

[jszakmeister]

Ah, got it. The environment variable is also prefixed: JE_MALLOC_CONF. 😧

I just found the same thing.

My initial question was how it was possible that neovim worked with jemalloc when it was well known that jemalloc was broken on macOS (I still have no idea how that was possible). I truly believe that this is the best place for this kind of questions (I recall, I tried IRC before asking here, but got no response). Of course, I’m open to other suggestions.

I looks to me like the initial question was whether we expected to build with jemalloc, and that was answered. :-) Honestly, since the concern you had was more about Neovim itself rather than the recipe, it would have been better to post the issue there where there is a wider audience. And more information about the issue you were actually seeing would have been valuable too.

Huh, now with the fixed jemalloc we will never be able to find out how it worked before. I gues, it doesn’t matter now.

I believe it works because we call je_malloc() directly and don't register a zone: https://github.com/neovim/neovim/blob/df072c3b2b20fb7d3d9d50b5ab0df92827aa628f/src/nvim/memory.c#L20

[kirelagin]

I believe it works because we call je_malloc() directly and don't register a zone

Yes, you a probably right. Thanks.