nativemem - Native memory profiler #1064

krk · 2024-11-26T19:30:27Z

Native memory allocations profiling and memory leak reporting, via GOT patching.

There is a new argument in the profiler nativemem, and jfrconv gains native memory tracking and memory leak reporting.

Usage

New argument --nativemem [N]/nativemem[=N] is used to enable the MallocTracer engine.
It can profile malloc, calloc, realloc and free invocations that are dynamically linked to the target.
When N is specified, only one allocation every N bytes is sampled.

Profiling with `nativemem`

java -agentpath:"$ASPROF_LIB/libasyncProfiler.so=start,nativemem,file=/dev/stderr" <app>

A flame graph can be generated directly as the profiler output option, which includes all sampled malloc calls. Alternatively, use jfrconv to process a jfr file and chart only the memory leaks:

Memory leak analysis via `jfrconv`

java -agentpath:"$ASPROF_LIB/libasyncProfiler.so=start,event=cpu,nativemem,file=malloc.jfr" <app>

jfrconv --total --nativemem --leak malloc.jfr malloc-leak.html

# without leak analysis, includes all collected samples:
jfrconv --total --nativemem malloc.jfr malloc.html

Generated flame graphs unit is in bytes if total is specified, otherwise in number of invocations.

asprof

If the profiler is attached via asprof, nativemem profiling can be started and stopped multiple times for the same process as necessary.

asprof start -e nativemem --total <app>
asprof stop <app>
...

How has this been tested?

New tests added that call malloc functions with and without multi-threading.

Sample outputs

All allocations

From a test application.

Memory leaks only

Profile of the same application, processed via jfrconv.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Native memory allocations profiling and memory leak reporting, via GOT patching.

apangin

Great work!

apangin · 2024-11-26T23:06:16Z

Makefile

+build-test-java-libs: $(addsuffix /.build-test,$(TESTS))
+%/.build-test:
+	@mkdir -p $(TEST_LIB_DIR)
+	@if [ -f test/test/$*/Makefile ]; then \


I'd leave everything in one root Makefile for now to keep things simple. IMO, recursive make is an overkill for running just one extra command. We can get back to this idea when the structure becomes more branched.

apangin · 2024-11-26T23:13:14Z

README.md

 - macOS x64/arm64: [async-profiler-3.0-macos.zip](https://github.com/async-profiler/async-profiler/releases/download/v3.0/async-profiler-3.0-macos.zip)
- Converters between profile formats: [converter.jar](https://github.com/async-profiler/async-profiler/releases/download/v3.0/converter.jar)  
-  (JFR to Flame Graph, JFR to pprof, collapsed stacks to Flame Graph)
+- Converters between profile formats: [converter.jar](https://github.com/async-profiler/async-profiler/releases/download/v3.0/converter.jar)


Two spaces intentionally meant a line break here.

Changed to a list.

apangin · 2024-11-26T23:23:25Z

docs/ConverterUsage.md

+    --nativemem        Generate native memory allocation profile
+    --leak             Only include memory leaks in nativemem


Move them after --live, since --live relates to --alloc as --leak to --nativemem.

Btw, will a single option that can be applied to either alloc or nativemem be better? (just an idea, I'm not proposing this).

We could have alloc=native, alloc=jvm, alloc=both options perhaps?

apangin · 2024-11-26T23:25:56Z

docs/ConverterUsage.md

 jfrconv --cpu foo.jfr
+
+# which is equivalent to:
+# jfrconv --cpu foo.jfr -o foo.html


The example is wrong. Sorry I haven't noticed that before.
It should be jfrconv --cpu -o flamegraph foo.jfr foo.html

apangin · 2024-11-26T23:42:54Z

src/profiler.cpp

+            if (VMStructs::_get_stack_trace != NULL) {
+                // Object allocation in HotSpot happens at known places where it is safe to call JVM TI,
+                // but not directly, since the thread is in_vm rather than in_native
+                num_frames += getJavaTraceInternal(jvmti_frames + num_frames, frames + num_frames, _max_stack_depth);


getJavaTraceInternal must not be used for nativemem, since it can allocate itself.

More generally, getJavaTraceInternal must not be used ever. I have recently removed it completely.

apangin · 2024-11-27T00:27:07Z

src/mallocTracer.cpp

+        return false;
+    }
+
+    CodeCache* lib = Profiler::instance()->findLibraryByName("libasyncProfiler");


It's not necessarily called like this. A library can have an arbitrary name, especially when extracted as a temporary file. Use findLibraryByAddress instead.

apangin · 2024-11-27T00:27:42Z

src/mallocTracer.cpp

+
+    lib->mark(
+        [](const char* s) -> bool {
+            return strncmp(s, "_ZL11malloc_hook", 16) == 0 || strncmp(s, "_ZL11calloc_hook", 16) == 0 || strncmp(s, "_ZL12realloc_hook", 16) == 0 || strncmp(s, " _ZL9free_hook", 13) == 0;


Break expression into several lines for better readability.

apangin · 2024-11-27T00:33:22Z

src/mallocTracer.cpp

+        return false;
+    }
+
+    MutexLocker ml(_patch_lock);


In theory, this may conflict with Hooks::patchLibraries() which has its own lock.
It makes sense to unify these two functions (also, to reduce copy-paste).
Can be done in a follow-up PR.

apangin · 2024-11-27T00:35:39Z

src/mallocTracer.cpp

+    event._address = (uintptr_t)address;
+    event._size = 0;
+
+    Profiler::instance()->recordSample(NULL, 0, MALLOC_SAMPLE, &event);


free calls are not sampled according to _interval.
It may be too expensive to record stack traces for each free. I therefore propose to record free events without a stack trace.

apangin · 2024-11-27T00:36:42Z

src/mallocTracer.cpp

+}
+
+Error MallocTracer::check(Arguments& args) {
+#ifndef __linux__


Try to avoid ifdefs in shared code when possible.
OS::isLinux() can help here (should be optimized by the compiler).

apangin · 2024-11-27T00:42:06Z

test/test/nativemem/CallsAllNoLeak.java

+        System.loadLibrary("doesmalloc");
+    }
+
+    public static native long nativeMalloc(int size);


To reduce code duplication, malloc wrappers can be moved to a separate Java class.

apangin · 2024-11-27T00:53:05Z

src/profiler.cpp

        char mark;
        if (current_method_name != NULL && (mark = NativeFunc::mark(current_method_name)) != 0) {
-            if (mark == MARK_VM_RUNTIME && event_type >= ALLOC_SAMPLE) {
+            if ((mark == MARK_VM_RUNTIME || mark == MARK_ASYNC_PROFILER) && event_type >= MALLOC_SAMPLE) {


For malloc events, it will be better to leave the first native frame to make it clear what function exactly was called (malloc/calloc/realloc).

apangin · 2024-11-27T01:01:49Z

src/converter/one/convert/JfrConverter.java

        long startTicks = args.from != 0 ? toTicks(args.from) : Long.MIN_VALUE;
        long endTicks = args.to != 0 ? toTicks(args.to) : Long.MAX_VALUE;
+        boolean allowZeroes = !args.nativemem;
+        IEventReader reader = eventFilter != null ? eventFilter : jfr;


Need to revise this approach - it will not work for multi-chunk JFRs.
An address map should persist between chunks.

IEventReader instance persists between collectEvents calls, as it is created in the JfrConverter ctor.

Went with a different design around the EventAggregator class.

krk · 2024-11-28T17:16:59Z

Addressed comments that have reactions or replies.

…ation (async-profiler#1066)

…sync-profiler#1068)

apangin · 2024-12-06T12:47:21Z

Makefile


+build-test-java-libs:
+	@mkdir -p $(TEST_LIB_DIR)
+	$(CC) -shared -fPIC $(INCLUDES) -I$(realpath src) -o $(TEST_LIB_DIR)/libdoesmalloc.$(SOEXT) test/test/nativemem/doesmalloc.c


Why realpath? Other targets are compiled fine without relative paths.

Was useful in the multi-makefile version, removing.

apangin · 2024-12-06T12:47:51Z

Makefile

 JAVA_TARGET=8
 JAVAC_OPTIONS=--release $(JAVA_TARGET) -Xlint:-options

+TEST_LIB_DIR=$(abspath build/test/lib)


Doesn't it work with relative path?

apangin · 2024-12-06T12:49:38Z

Makefile

  PROFILER_VERSION := $(PROFILER_VERSION)-$(COMMIT_TAG)
 endif

+SOEXT ?= so


SOEXT is already defined appropriately depending on ifeq ($(OS),Darwin)

apangin · 2024-12-06T12:50:34Z

Makefile

 	echo "Running tests against $(LIB_PROFILER)"
-	$(JAVA) $(TEST_FLAGS) -ea -cp "build/test.jar:build/jar/*:build/lib/*" one.profiler.test.Runner $(TESTS)
+
+	LD_LIBRARY_PATH="$(TEST_LIB_DIR)" $(JAVA) $(TEST_FLAGS) -ea -cp "build/test.jar:build/jar/*:build/lib/*" one.profiler.test.Runner $(TESTS)


LD_LIBRARY_PATH is Linux-specific. Use -Djava.library.path instead.

apangin · 2024-12-06T13:03:12Z

test/test/nativemem/doesmalloc.c

+}
+
+JNIEXPORT void JNICALL Java_test_nativemem_Native_free(JNIEnv* env, jclass clazz, jlong addr) {
+    free((void*)addr);


Does this compile on a 32-bit system? I guess an intermediate conversion to intptr_t is needed.

apangin · 2024-12-06T13:09:53Z

.assets/images/nativemem_flamegraph.png

Can we have a more realistic flamegraph?
I used to show native memory leaks on this example (strictly speaking, it's not fully a leak, since finalizers are supposed to free native resources, but in practice, finalizers can be very unpredictable).

Changed with a "ByteBuffer leak while reading a stream" scenario.

apangin · 2024-12-06T13:12:38Z

docs/ProfilingModes.md


+## Native memory leaks
+
+It is possible to profile `malloc` and `mmap` calls in Java context before, not always helpful. A large amount of allocations does not yet mean a leak, in case all the allocated memory is released on time.


Something wrong with the first sentence, can you rephrase it?

apangin · 2024-12-06T13:13:39Z

docs/ProfilingModes.md

+```
+asprof start --nativemem[=N] <YourApp>
+
+asprof stop -f <app.jfr> <YourApp>


With JFR output, filename must be given in start command.

apangin · 2024-12-06T13:16:20Z

test/test/nativemem/Native.java

+
+public class Native {
+    static {
+        System.loadLibrary("doesmalloc");


Unobvious name. Maybe jnimalloc?

apangin · 2024-12-06T13:19:41Z

src/mallocTracer.cpp

+}
+
+#ifdef __linux__
+extern "C" WEAK DLLEXPORT void* malloc(size_t size) {


Does nativemem profiler work with non-Java apps if async-profiler is LD_PRELOAD'ed?

Yes, tested manually.

MattAlp · 2024-12-07T13:54:44Z

Very nice, thanks for contributing this

r1viollet · 2024-12-10T08:50:07Z

src/codeCache.h

    im_pthread_exit,
    im_pthread_setspecific,
    im_poll,
+    im_malloc,


In case it is helpful, here are some of the functions we had to hook: https://github.com/DataDog/ddprof/blob/bccb05d89ec9e8473cd7f4f26d4e4948a70839c8/src/lib/symbol_overrides.cc#L852-L899
Though I realize you might not need to have a full coverage for now.

Thanks for the link. We could implement these in another iteration or prioritize based on customer requests.

r1viollet · 2024-12-10T14:55:36Z

src/mallocTracer.cpp

+    }
+}
+
+void MallocTracer::recordFree(void* address) {


Am I correct in saying we do not have a sampling decision here (as we do not want to miss matching frees) ?
Here we proposed to record only free events for tracked addresses. However that meant having a lock free data structure containing tracked addresses.
The ideal solution might be to have more control over the allocator being used, to embed such a logic within the allocated object.

Yes, we do not have a sampling decision for free and wanted to avoid having to keep a list of allocation addresses.

r1viollet · 2024-12-10T15:35:26Z

src/profiler.cpp

    void* result = dlopen(filename, flags);
    if (result != NULL) {
        instance()->updateSymbols(false);
+        MallocTracer::installHooks();


While relying on a similar strategy, I recall we were not able to catch all loaded libraries. We eventually decided to put a timer that would trigger and recheck loaded libraries every X seconds (in addition to the dlopen hook). If this is of interest, I can find more details.

It would be interesting to understand when this can happen.

I found the commit thanks to @nsavoire. A private symbol can be used to dlopen __libc_dlopen_mode.
DataDog/ddprof@d0bb6c6

r1viollet · 2024-12-10T15:48:35Z

Exciting to see memory profiling as part of async profiler! 👏 I mentioned a few of the gotchas we encountered while implementing something similar in case this can be of interest.

This reverts commit 976449c.

This reverts commit 45d357d.

This reverts commit a075086.

apangin · 2024-12-12T23:57:59Z

docs/ProfilingModes.md

+
+```
+asprof start -e nativemem -f app.jfr <YourApp>
+# asprof start --nativemem=N -f app.jfr <YourApp>


--nativemem N (no =)

apangin · 2024-12-13T01:34:07Z

src/converter/one/convert/JfrConverter.java

 public abstract class JfrConverter extends Classifier {
    protected final JfrReader jfr;
    protected final Arguments args;
+    private final IEventAggregator leakAggregator;


It feels like a leaky abstraction (pun intended): we pretend it to be some abstract aggregator, although we know it can be only MallocLeakAggregator.

apangin · 2024-12-13T01:38:12Z

src/converter/one/convert/JfrConverter.java

+                leakAggregator.coarsen(args.grain);
+            }
+
+            convertChunk(leakAggregator);


An illustration to the above comment: we have a special case for leakAggregator, but trying to deal with it as with some generic aggregator.

Can we design it in a way that we either have a common sequence for any aggregator or don't pretend that leak processor is an aggregator at all and just make leak processor explicitly a different thing?

For example, to consolidate EventAggregator (currently created for each new chunk) and LeakAggegator (a single instance for the whole process) we may probably replace creation of a new EventAggregator with clearing/resetting the same instance of EventAggregator. (Just as an idea; I'm open for other options too).

Removing the leak and special-cased invocations.

apangin · 2024-12-13T01:50:59Z

src/converter/one/jfr/event/EventAggregator.java

    }

-    public void collect(Event e, long samples, long value) {
+    protected void collect(Event e, long samples, long value) {


This is a public API that is currently used in other projects.

apangin · 2024-12-13T01:53:23Z

src/converter/one/jfr/event/SortedEventAggregator.java

+import java.util.ArrayList;
+import java.util.Collections;
+
+public abstract class SortedEventAggregator extends EventAggregator {


Redundant abstractions, IMO.
There are currently only two aggregators. If we go this way, we can just make MallocLeakAggregator a subclass of EventAggregator.

Folding SortedEventAggregator into MallocLeakAggregator.

apangin · 2024-12-13T01:56:06Z

src/mallocTracer.cpp

+
+__attribute__((constructor)) static void getOrigAddresses() {
+    // Set malloc and calloc which may be called from libc during getOrigAddresses.
+    _orig_malloc = OS::safeAlloc;


So is it really necessary? I remember you were saying allocation in dlsym only happens on error path, and returning NULL does not break anything.

For a specific libc version yes. Removing to see test results.

apangin · 2024-12-13T01:59:10Z

test/native/testRunner.hpp

 #define __ASSERT_OR_CHECK_OP(isAssert, val1, op, val2)                                                               \
    {                                                                                                                \
+        _Pragma("GCC diagnostic push");                                                                              \
+        _Pragma("GCC diagnostic ignored \"-Waddress\"");                                                             \


This is getting more and more intricate.
Would not it be better to have a special version of macros for strings?

We could split it at some point.

apangin · 2024-12-13T17:47:57Z

src/converter/one/convert/JfrConverter.java

        this.jfr = jfr;
        this.args = args;
+
+        IEventAggregator agg = new EventAggregator(args.threads, args.total, args.lock ? 1e9 / jfr.ticksPerSec : 1.0);


ticksPerSec is only available after reading chunk header. In theory, it may be different for different chunks.
Actually, this value is required only during post-processing (in forEach), so it probably makes sense to move it out of constructor.

apangin · 2024-12-13T17:51:23Z

src/converter/one/convert/JfrConverter.java

-                args.live ? LiveObject.class :
-                        args.alloc ? AllocationSample.class :
-                                args.lock ? ContendedLock.class : ExecutionSample.class;
+    protected IEventAggregator collectEvents() throws IOException {


Previously, collectEvents created and owned an aggregator. Now it always uses a singleton created in a constructor. There is no sense in returning an aggregator then?

Similarly, convertChunk does not need an acceptor argument.

apangin · 2024-12-13T17:54:39Z

src/converter/one/convert/JfrConverter.java

+    protected IEventAggregator collectEvents() throws IOException {
+        Class<? extends Event> eventClass = args.live ? LiveObject.class
+                : args.alloc ? AllocationSample.class
+                        : args.lock ? ContendedLock.class : args.nativemem ? MallocEvent.class : ExecutionSample.class;


IMO, previous formatting was more readable.

apangin · 2024-12-13T17:56:53Z

src/converter/one/convert/JfrConverter.java


-    // millis can be an absolute timestamp or an offset from the beginning/end of the recording
+    // millis can be an absolute timestamp or an offset from the beginning/end of
+    // the recording


Seems like an automatic reformatting. In general, prefer to avoid reformatting code unrelated to the PR.

apangin · 2024-12-13T17:58:38Z

src/converter/one/jfr/event/EventAggregator.java

+    }
+
+    public void resetChunk() {
+        this.fraction = 0;


fraction is relevant only for coarsen method - I'd reset it in the beginning of coarsen instead.

apangin · 2024-12-13T18:07:14Z

src/converter/one/jfr/event/IEventAcceptor.java

+
+package one.jfr.event;
+
+public interface IEventAcceptor {


I understand why you added this, but imo this is unnecessary level of abstraction.
Fortunately, as per my other comment, the only use of IEventAcceptor (and therefore IEventAcceptor itself) can be safely removed.

apangin · 2024-12-13T18:12:33Z

src/mallocTracer.cpp

+
+#ifdef __linux__
+extern "C" WEAK DLLEXPORT void* malloc(size_t size) {
+    if (unlikely(!_orig_malloc)) {


Should we check MallocTracer::initialized() first? (to make less comparisons on the fast path)

apangin · 2024-12-13T18:17:32Z

src/profiler.h

+# ifndef likely
+#  define likely(x)     (__builtin_expect(!!(x), 1))
+# endif
+
+# ifndef unlikely
+#  define unlikely(x)   (__builtin_expect(!!(x), 0))
+# endif


profiler.h is probably not the right place for these macros, they are only used in mallocTracer.cpp, you can put them there. Or, to make them available for a wider use, arch.h will fit better.

apangin · 2024-12-13T18:38:26Z

src/converter/one/jfr/event/MallocLeakAggregator.java

+            }
+        }
+
+        return new ArrayList<>(addresses.values());


The list of "filtered" events is not actually used, is it? Therefore, creating ArrayList seems redundant.

It is used in multi-chunk jfrs, filtered events will be sorted together with new events, before filtering again.

But why? Timestamps of malloc events from different chunks should not overlap. Do they?

apangin · 2024-12-13T18:42:17Z

src/converter/one/convert/JfrConverter.java

+        eventAggregator.finishChunk();

        if (args.grain > 0) {
-            agg.coarsen(args.grain);
+            eventAggregator.coarsen(args.grain);
        }


finishChunk and coarsen can be moved out of collectEvents.

apangin · 2024-12-13T18:53:18Z

src/converter/one/convert/JfrConverter.java

+        convertChunk(eventAggregator);
+        eventAggregator.resetChunk();


From the design perspective, it looks strange that convertChunk/resetChunk are called again after finish.
I understand they are needed only for MallocLeakAggregator to process the final filtered list, but I think this should be somehow hidden in finish.

Moving them to their own method, to make the intent clearer.

Signed-off-by: Andrei Pangin <1749416+apangin@users.noreply.github.com>

apangin · 2024-12-16T14:10:44Z

I've pushed a fix for recording timestamps correctly. Other than that, PR looks good. There is still one question about filtering events after each chunk, but it's not a blocker right now. Merged. Thanks a lot!

linking12 · 2025-05-21T11:32:06Z

@krk @apangin We found this running under jemallo will cause the process to crash，Do we have a fixed version?

apangin · 2025-05-21T12:21:51Z

@linking12 Yes, please try a nightly build.

Native memory profiler.

93a9019

Native memory allocations profiling and memory leak reporting, via GOT patching.

krk changed the title ~~Natmemtracker~~ nativemem - Native memory profiler Nov 26, 2024

apangin reviewed Nov 27, 2024

View reviewed changes

krk added 2 commits November 28, 2024 17:04

address comments

dbe47b0

add back ifdefs on exports

dd42f51

krk and others added 8 commits December 2, 2024 16:30

address comments

c989f0c

add multi-chunk support to the converter.

8add99f

Fix misses and build issues in Non Java profiling example in document…

2f10647

…ation (async-profiler#1066)

Count missed samples when estimating total CPU time in ctimer mode (a…

5408286

…sync-profiler#1068)

Fixed JFR test on macOS

e797c2e

Revised fix for JfrTest.regularPeak test

88770e4

update docs

2b506ef

Merge branch 'master' into natmemtracker

4cea91b

apangin reviewed Dec 6, 2024

View reviewed changes

krk added 2 commits December 6, 2024 16:27

address comments

0afb39e

Merge branch 'master' into natmemtracker

c9db48f

r1viollet reviewed Dec 10, 2024

View reviewed changes

krk added 3 commits December 10, 2024 13:56

Merge branch 'master' into natmemtracker

33f84d2

suppress Waddress

c13ec86

fix macos build warnings

9424bd0

r1viollet reviewed Dec 10, 2024

View reviewed changes

krk added 4 commits December 10, 2024 20:05

support macos.

a075086

dbg mac github actions

45d357d

dbg mac github actions

976449c

Revert "dbg mac github actions"

11d3195

This reverts commit 976449c.

krk added 4 commits December 10, 2024 20:54

Revert "dbg mac github actions"

4e2daf6

This reverts commit 45d357d.

Revert "support macos."

d1090ee

This reverts commit a075086.

fix typo

f00d0bd

Merge branch 'master' into natmemtracker

3396e02

apangin reviewed Dec 13, 2024

View reviewed changes

krk added 2 commits December 13, 2024 14:53

address comments, fold SortedEventAggregator into MallocLeakAggregator.

5c273d0

use composition instead of inheritance, remove special cases

3f3e92e

apangin reviewed Dec 13, 2024

View reviewed changes

krk and others added 2 commits December 13, 2024 20:06

address comments

af428bf

Use RDTSC for timestamps instead of OS::nanotime

8239df6

Signed-off-by: Andrei Pangin <1749416+apangin@users.noreply.github.com>

apangin merged commit 78f78cf into async-profiler:master Dec 16, 2024
10 checks passed

franz1981 mentioned this pull request Jan 28, 2025

Adaptive: memory oom issue netty/netty#14598

Closed

korniltsev mentioned this pull request Apr 14, 2025

add support for asprof native mem profiling grafana/pyroscope-java#195

Open

yysindi mentioned this pull request May 16, 2025

Add support for Native Memory Profiling (nativemem) via async-profiler async-profiler/rust-agent#41

Closed

apangin mentioned this pull request May 18, 2025

Skip last 10% allocations for leak detection #1299

Merged

		--nativemem Generate native memory allocation profile
		--leak Only include memory leaks in nativemem


		## Native memory leaks

		It is possible to profile `malloc` and `mmap` calls in Java context before, not always helpful. A large amount of allocations does not yet mean a leak, in case all the allocated memory is released on time.

nativemem - Native memory profiler #1064

nativemem - Native memory profiler #1064

Uh oh!

Conversation

krk commented Nov 26, 2024

Usage

Profiling with nativemem

Memory leak analysis via jfrconv

asprof

How has this been tested?

Sample outputs

All allocations

Memory leaks only

Uh oh!

apangin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

krk commented Nov 28, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattAlp commented Dec 7, 2024

Profiling with `nativemem`

Memory leak analysis via `jfrconv`

r1viollet Dec 10, 2024 •

edited

Loading