Feature: Add memory allocation information to thread model.

[Hohensee, Paul]

Hi, Kartik,

The info you want is available from com.sun.management.ThreadMXBean.getThreadAllocatedBytes(). See, e.g.,

https://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/ThreadMXBean.html

I don't think a resetAllocatedBytes method is needed. Your application can just save the current allocatedbytes value, do work, and then subtract the saved value from the new current value.

Thanks,
Paul

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> on behalf of Kartik Kalaghatagi <kartik.kalaghatagi at gmail.com>
Date: Wednesday, June 2, 2021 at 4:00 AM
To: "hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>
Subject: Feature: Add memory allocation information to thread model.

Hi JDK Team,

I would like to add a new feature to native C++ thread implementation
located at 'hotspot\share\runtime\thread.cpp". Before I explain what the
changes are, I want to share what problem it solves.

Q. What is the current challenge/problem we have?
A. Today Java is being used by many companies and has been running in
production for decades. And since many cloud-based companies are evolving
and supporting multi-tenants, there is a very big challenge in terms of
memory. Currently, we have many tools like VisualVM, JVMTI agents which
profile the memory (heap) and gives us the information of how much memory
is being used. And this profiling adds significant cost when repeated
regularly. We need to take the heap dump, analyze it and then understand by
GC roots to figure out how much memory the thread was consuming and how it
caused Out-of-memory and impacted other customers. Also, there is no
isolation between tenants, currently, we can't say a standard customer is
allowed to process only 100MB of memory to do the work while a premium
customer gets to process 1GB, because nowhere we get this information on
how much memory the thread is using during runtime.

Q. What is the solution?
A. If we introduce a variable that will hold the information about the
amount of memory allocated since the start of the thread. At any given
point in time, the application now has a context on how much memory the
thread is using. With Aspect-oriented programming evolving we can intercept
the 'start' and 'end' point, where the thread will do its work, between
this we can reset the allocation value OR the same can be achieved by
writing agent using JVMTI.

*Implementation overview.*
I am proposing 2 ways we can get this information.

   1. We can add 2 functions to the thread object "getAllocatedBytes()" and
   "resetAllocatedBytes()" and in the java application we can control the
   threads based on memory usage and prevent the system from going down
   because of Out-of-memory.
   2. We can add a JVMTI function to extract this information. and spawn an
   agent thread to monitor the memory usage of all other threads and take
   appropriate action.


*Performance and corner cases.*
I guess there won't be any performance impact since we are not waiting for
the JVM to go to a safe state as it happens while taking heap dump.
Also, there won't be any overflow since the variable is of type 'long'
whose value is 2**64 and it takes the thread to
allocate 18446.744073709553049 petabytes of memory and in an ideal case JVM
will be restarted within this, even if overflow occurs the value will reset
to zero.


I would appreciate any comments on this and also correct me if I am wrong
or missed anything.

Regards,
Kartik