RFR: 8338888: SystemDictionary::class_name_symbol has incorrect length check

[David Holmes]

On Wed, 28 Aug 2024 01:43:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I get what you mean, but then, we should take the limit you impose here (print_limit) at face value and act as if Exceptions::fthrow would not impose any limits (since we cannot know them since they are implementation details).
>> 
>> So, again there is the question if we want to pay 2 GB (multiple times, since we need a buffer for vsprintf to assemble it, then memory in java heap for the resulting j.l.String). Something akin to your log messages where we omit the middle of the string may serve us here as well. Or, just a bigger but still reasonable limit (e.g. 512 KB).
>
> You're right. I can apply the "abridged" pattern here as done in `java_lang_String::print` using the `MaxStringPrintSize` global. But this is now encroaching on the remedial actions I planned to undertake for [JDK-8328882](https://bugs.openjdk.org/browse/JDK-8328882).  I only need this change in this PR to handle the test case for the actual bug fix (otherwise I have to drop the part of the test that verifies it is the expected error message).
> 
> I will look at creating a sub-task of JDK-8328882 to handle callers of `Exceptions::fthrow` and fix this issue under that task first.

Well I created a sub-task as I indicated and it turned out that most places are safe but can still have "names" up to 64K, but the nature of the error messages are such that they are not really amenable to abridged versions, plus you may need the full name to actually see the error. So in that regard I think `fthrow` is actually wrong to impose its own 1K limit as it will prevent you from debugging things - in some cases long before you get anywhere near excessive individual names.

But back to the individual case at hand ... given we know its a giant name and its going to get truncated anyway, then the abridged version is better IMO as I still contend that given it is an erroneous condition it is most likely the error occurred at the start or end (I've absolutely no data to back that up : ) ).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20709#discussion_r1734042031