On Mon, 30 Mar 2026 12:36:55 GMT, Thomas Stuefe <[email protected]> wrote:
> Some small QOL improvement and trivial fixes: > - System.dump_map now takes the filename as a positional argument, which > makes for less awkward handling > - System.dump_map now allows %t as a placeholder in its filename, and the > default filename now contains a timestamp (reusing the logic in > `make_log_name` for this) > - `make_log_name` returns a C-heap allocated array and therefore should not > return a `const char*` but a `char*`. > - Used the more common - in our code base - `_WINDOWS` instead of `_WIN64` > - Removed the "(linux, Windows and MacOS only)" output since this code never > runs on other platforms (not compiled for AIX or *BSD) > - since the filename argument has a default value if omitted by the user, it > can never be empty - assert that instead of doing runtime checks Hi, Maybe it's a good time to bring up that it's odd to have System.map and System.dump_map, i.e. two commands for the same thing. If it was an optional dump filename, these would be one command? If System.map has the filename as an optional (positional) argument, it can't have a default output filename. But having a default filename doesn't seem very important. I realise we also have Thread.dump_to_file and that is an example of a command very similar to another command, which outputs to a file. But that doesn't mean having a different command to choose to write out to a file is a good pattern, it doesn't scale well if various commands want to optionally write to a file (we could double the number of jcmds!). ------------- PR Comment: https://git.openjdk.org/jdk/pull/30497#issuecomment-4175657639
