RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9]

Kevin Walls kevinw at openjdk.org
Thu Jul 25 11:40:35 UTC 2024


On Wed, 24 Jul 2024 17:54:30 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticArgument.hpp line 65:
>> 
>>> 63: class FileArgument {
>>> 64:   private:
>>> 65:     char _name[1024];
>> 
>> Probably JVM_MAXPATHLEN (which might also be 1024).
>
> Hi, I avoided JVM_MAXPATHLEN because of this comment https://github.com/openjdk/jdk/pull/20198#discussion_r1685297940

It seems strange to me to NOT use MAXPATHLEN (or JVM_MAXPATHLEN), in this one particular place, based on if somebody rebuilds the JDK on a system where it is defined to be very very long, then there would be some unnecessarily large allocations.

There are approx 140 other uses.

If JVM_MAXPATHLEN is 4k, we are saying that those other usages reserve the 4k, but this particular path should max out at 1024 bytes?

Given common cloud paths and even in our test systems, paths are commonly nearly 400 bytes, so 1024 is not that much spare capacity.

I don't want to contradict @tstuefe too much, and it's not make or break for this change, but I would think just go with the standard max path len used everywhere else.  If there's a problem with memory bloat, then hardcoding one of the usages isn't really going to help much.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1691299887


More information about the serviceability-dev mailing list