Just to clarify the issue. The size 1024 is an internal buffer limit that fthrow uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which os::vsnprintf will try to calculate and report. The intent is to check callers can't hit that underlying vsnprintf INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using %*s.

For example, in SystemDictionary::class_name_symbol we already report abridged messages using a similar style to the print limit in java_lang_String::print and the MaxStringPrintSize flag. Sample output:

[2.352s][info][exceptions] Exception <a 'java/lang/NoClassDefFoundError'{0x0000000454d97408}: Class name exceeds maximum length of 65535: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz ... (65280 characters omitted) ... zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz> (0x0000000454d97408)
thrown [/scratch/users/daholme/jdk-dev4.git/open/src/hotspot/share/classfile/systemDictionary.cpp, line 270]

Some code already imposes its own smaller limits that we extend to cover missing cases (e.g. DCmdArgument parsing).

For most code we simply add a comment reflecting that the call cannot be excessively large due to what is printed i.e. it only prints symbols which each must be < 64K.