Hi Maxim, It seems like you're trying to make a cumulative per-thread allocation counter. There is already such counter available out-of-the-box, see ThreadMXBean.getThreadAllocatedBytes http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/73d5bcd0585d/src/share/classes/com/sun/management/ThreadMXBean.java#l145
понедельник, 5 февраля 2018 г., 18:20:47 UTC+3 пользователь Maxim Terletsky написал: > > Hi guys, > I have a need to check memory allocations in our Java server per Thread. > For that purpose I modified slightly the Async Profiler > <https://github.com/jvm-profiling-tools/async-profiler> tool. As we can > see in allocTracer.cpp > <https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/allocTracer.cpp> > file, > it registers for those two events - send_allocation_outside_tlab_event > <https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/allocTracer.cpp#L26> > > and send_allocation_outside_tlab_event > <https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/allocTracer.cpp#L27> > > . Now, in my Java app I did some simple testings with > > allocationStart1 = > AsyncProfiler.getInstance().getAndZeroTotalAllocationsPerThread() > > ArrayList aa = new ArrayList(); > for (int i = 0; i < 14000; i++) { > aa.add(RandomStringUtils.randomAlphanumeric(100)); > } > allocationsEnd1 = AsyncProfiler.getInstance(). > getAndZeroTotalAllocationsPerThread(); > > getAndZeroTotalAllocationsPerThread is my adding to AsyncProfiler JNI, > approximately returning the memory calculated by > static __thread u64 _total_counter_per_thread; > .. > void Profiler::recordSample(void* ucontext, u64 counter, jint event_type, > jmethodID event) { > _total_counter_per_thread += counter; > } > This code replaces original Profiler::recordSample > <https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/profiler.cpp#L278> > method. > > Now, since we are talking about TLAB and not just an event that fires on > every memory allocation, this memory is not straightforward. If I make "aa" > to be "static" than it's much more predictable since it actually grows and > takes more and more TLABs. > > So my question is basically whether this approach is feasible in your > opinion? Or, because those events will fire only when objects are allocated > outside of TLAB/in new TLAB, I won't have anything useful from it? > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
