RFR: 8255416: Investigate err_msg to detect unnecessary uses [v4]

[Anton Kozlov]

On Thu, 29 Oct 2020 08:47:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Oh, now I see it. Smart.
>> 
>> But it occurred to me that someone may want to start a err_msg buffer up with a string literal, only to then add additional content via FormatBuffer::append(). So initializing it with a literal and no arguments may be a valid usecase. 
>> 
>> So I'd still prefer keeping this out. Alternatively, if you like to keep it in, could we just not implement the second constructor? Which should give us linker errors if the static check fails.
>
> +1 to leave this undefined to get a linkage error. There are already precedents to do this in Hotspot code, for example
> 
>   Node(const Node&);            // not defined; linker error to use these
>   ...
>   // should never be used
>   AdapterHandlerEntry();

This is a good suggestion. Link-time failure is certainly better than runtime one, thanks!

Although err_msg was implemented with FormatBuffer since the beginning [1], I assume it should be an implementation detail. Otherwise there would be no function-like err_msg thing. And at the present, there is only a single case of append to err_msg.

FormatErrBuffer can inherit FormatBuffer privately. It will completely remove err_msg interface relation with FormatBuffer, which is aligned with the most of current uses.

Although I don't clearly understand reasons not to introduce this (beside it may be a bit over-engineered, but without implications to maintainability, I suppose), this may change assumptions about err_msg.

[1] http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f03d0a26bf83#l32.32

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

PR: https://git.openjdk.java.net/jdk/pull/905