Fix review findings: torn write, stale comments, doc inaccuracies

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: jbachorik

ddprof-lib/src/main/cpp/thread.h

@@ -213,8 +213,7 @@ class ProfiledThread : public ThreadLocalData {
   }
 
   inline void cacheJavaThread(bool isJava) {
-    if (isJava) _misc_flags |= FLAG_JAVA_THREAD;
-    _misc_flags |= FLAG_JAVA_THREAD_KNOWN;
+    _misc_flags |= FLAG_JAVA_THREAD_KNOWN | (isJava ? FLAG_JAVA_THREAD : 0);
   }
 
 private:

ddprof-lib/src/main/cpp/vmEntry.cpp

@@ -323,9 +323,9 @@ bool VM::initShared(JavaVM* vm) {
   // on musl in libc.musl-<arch>.so.1; on Rust they may be in the app binary itself.
   // Scanning all libs avoids fragile name-based lookup (findLibraryByName uses a
   // prefix match that can return the wrong library, e.g. libcap instead of libc).
-  // walkVM emits break_no_anchor when it reaches the top of a pure-native thread
-  // stack without finding an anchor; marking start_thread/thread_start here gives
-  // the walker a clean stopping point for any pthread-managed thread.
+  // walkVM stops unwinding when it reaches the top of a pure-native thread stack
+  // without finding an anchor; marking start_thread/thread_start here gives the
+  // walker a clean stopping point for any pthread-managed thread.
   const CodeCacheArray& all_native_libs = libraries->native_libs();
   for (int i = 0; i < all_native_libs.count(); i++) {
       all_native_libs[i]->mark(isThreadEntry, MARK_THREAD_ENTRY);

doc/architecture/NativeMemoryProfiling.md

@@ -176,10 +176,11 @@ NULL`). Native stack unwinding via frame pointers or DWARF requires a signal con
 as the starting point, so neither `CSTACK_DEFAULT` nor `CSTACK_FP` can produce
 useful traces for malloc events.
 
-`CSTACK_VM` uses HotSpot's `JavaFrameAnchor` (lastJavaPC / lastJavaSP / lastJavaFP)
-to walk Java frames, and falls back to `__builtin_return_address` for the native
-portion. This works correctly from inside a malloc hook because the anchor is set
-whenever the JVM has transitioned from Java to native.
+`CSTACK_VM` starts from `__builtin_return_address` for the initial frame and walks
+native frames via DWARF. It then uses HotSpot's `JavaFrameAnchor` (lastJavaPC /
+lastJavaSP / lastJavaFP) to transition from native to Java frames. This works
+correctly from inside a malloc hook because the anchor is set whenever the JVM has
+transitioned from Java to native.
 
 ### Default stack mode
 
@@ -282,9 +283,10 @@ which passes `call_trace_id = 0` (JFR null-reference convention).
 > not used. Reentrant allocation calls would result in double-accounting.
 
 When `recordMalloc` calls into the profiler (stack walking, JFR buffer writes), any
-allocations made by the profiler itself will re-enter the hooks. Because those
-internal allocations call `_orig_malloc` directly (not the hook), there is no
-infinite recursion, but they may be double-counted as application allocations.
+allocations made by the profiler itself will re-enter the hooks. Infinite recursion
+is prevented because the hook functions call `_orig_malloc` (a saved direct function
+pointer) instead of going through the GOT, but profiler-internal allocations may be
+double-counted as application allocations.
 Leak detection is unaffected: the same address being recorded multiple times is
 handled correctly by the tracking logic.