RFR (L) JDK-8230199: consolidate signature parsing code in HotSpot sources

[John Rose]

On Jan 27, 2020, at 5:20 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Question: in signature.cpp, is there any tangible benefit to do this:
> 
> while (end < limit && (char)base[end++] == JVM_SIGNATURE_ARRAY) { }
> --end;  // skipped a non-'['
> 
> rather than:
> 
> while (end < limit && (char)base[end] == JVM_SIGNATURE_ARRAY) { end++; }

It was my “writer’s privilege” to put it that way, and I suppose
it’s “reviewer’s privilege” to object and have it put a different way.

Just FTR, there is a benefit to the way I put it:  Every read of every
character in the buffer was of the form `buf[end++]`, so it as if
the logic uses “getc”, with an occasional “ungetc” (`--end`).
The new form of the logic has different kinds of accesses
to the stream of chars:  “getc”, “peekc” (`buf[end]`), and
“skipc” (`end++`).  By my count that’s more kinds of access,
and when I read such parsing code I find that fewer kinds
of access are less disruptive to a close reasoning about the
parse logic.  So in my subjective opinion as a coder, I
thought one way was clearer than the other, but I’m happy
to accept a consensus that the other way is, in fact, clearer
to more people.

BTW, it’s very unlikely that such stylistic differences would
make any difference in the optimized code emitted by the C++
compiler.  For my part, whenever I write C++ code whose
form is intended to affect optimization in a subtle way, I
try to remember to write comments explaining why the
code is the way it is, so that maintainers won’t try to make
it prettier without taking into account the reason the code
is the way it is.

— John