Is it safe to use LD_PRELOAD to load a custom malloc library when running the OpenJDK?

[David Holmes]

On 18/10/2024 9:13 am, 기준 wrote:
> Hello everyone, hope you're doing well!
> 
> I have a question, and I’m hoping this is the right place to ask. If 
> it's not, I’d appreciate it if someone could point me to the correct 
> mailing list.

Just to be clear these lists are for hotspot developers to use to 
discuss hotspot development, not for end users to ask about running Java.

That said ...

> Our team is heavily using JNI C++ code for computations that involve 
> frequent object allocations and deallocations. To optimize these memory 
> operations, we tested using |jemalloc| as a replacement for |glibc|, and 
> observed huge improvements in performance metrics.
> 
> We're currently using |LD_PRELOAD| to load the |jemalloc| library when 
> launching the JVM, so that all memory allocation and deallocation 
> requests are handled by |jemalloc|. However, I'm wondering if this 
> approach could lead to any unexpected issues, since it would also take 
> the JVM's memory allocation requests as well.
> 
>  From what I understand, heap allocations in the JVM don't use |malloc| 
> directly, as they rely on optimized assembly code or the JVM's internal 
> memory management system. Some folks on the internet have mentioned that 
> the JVM might have a custom |malloc| implementation designed 
> specifically for its use, preloading jemalloc may cause 
> symbol conflicts. However, I haven't been able to find any code 
> supporting that hypothesis.
> 
> *_My question is: is it safe to use |LD_PRELOAD| to load a custom | 
> malloc| library, like |jemalloc|, when running the JVM, at least with 
> OpenJDK?_*

I've heard of numerous people doing this over the years. Hotspot uses 
custom internal allocators, but it doesn't replace the system malloc.

malloc-replacmeent libs like jemalloc sometimes expose bugs that the 
regular system mallocs have hidden ref:

https://bugs.openjdk.org/browse/JDK-8215355

HTH,
David

> 
> 
> Thank you in advance.
> 
> Dooyong Kim
>