Re: Re: jfr view: Regarding adding "Allocated" column to the allocation related 3 views

[Long Yang]

Hi Erik

Thank you for your reply.

The query language designed in `jfr view` is an excellent idea. You can query JFR file as a database.

I saw that the weight of jdk.ObjectAllocationSample is obtained by comparing the difference in thread->allocated_bytes() between the two events. It is not the size of the actual object or the size of the TLAB.

For allocation-by-thread, if the Allocated field is added, the result is almost the same as thread-allocation. (However, because thread-allocation already exists, it is no longer necessary to add the Allocated field to allocation-by-thread.)

For allocation-by-class and allocation-by-site, if the Allocated field is added, the Allocated sum of all Classes or all Sites should be close to the actual sum, and there will be no obvious difference due to the sample mechanism. 
From this point, adding 'Allocated' is feasible.

However, we also know that for the weight in each event, its value is the difference between two thread->allocated_bytes(). The added 'Allocated' field cannot accurately represent the actual memory allocated by Site or Class. 
It can only be said from from a statistical perspective, there is a large correlation.

If what you concerned is the 'Allocated' field cannot accurately represent the amount of memory requested by the actual Site or Class, I agree.
If what you concerned is the difference between the total number of 'Allocated' and the actual amount of memory allocated, I feel that adding this field should be no problem.

Best Regards


 ------------------Original Mail ------------------
Sender:Erik Gahlin <erik.gahlin at oracle.com>
Send Date:Wed Mar 20 17:56:23 2024
Recipients:Long Yang <yibo.yl at alibaba-inc.com>, hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject:Re: jfr view: Regarding adding "Allocated" column to the allocation related 3 views

Hi,

The value is sample-based and only a rough estimate. That's why only a percentage is shown. The purpose is to find the worst offenders. Thread allocation is more precise as it looks at a byte value stored in the thread.

(I might come off as negative to your suggestions, but when I implemented 'jfr view' I tried many different views and layouts, only the best made it. The main reason I created the query language was so I could quickly try things out.)

Erik
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Long Yang <yibo.yl at alibaba-inc.com>
Sent: Wednesday, March 20, 2024 3:46 AM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: jfr view: Regarding adding "Allocated" column to the allocation related 3 views
hi all

jfr view has three predefined views regarding allocation: allocation-by-thread,allocation-by-class, allocation-by-site.
Currently, these three views only show percentages. 
Usually, we will first look at the absolute value of memory application (total number of allocated bytes). 
When the absolute value is larger enough, the items with larger proportions are more meaningful.
I don’t know if I can add Allocated column to these three views, similar to thethread-allocation view.

                                            Allocation by Class
Object Type                                                    Allocated Allocation Pressure
--------------------------------------------- ---------------- -------------------
byte[]                                                                 11.7 GB              99.82%

Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20240321/bd052e64/attachment.htm>