RFR: 8303078: Reduce allocations when pretty printing JCTree during compilation

[Christoph Dreis]

Hi,

I've been recently optimizing a few project pipelines and always noticed that their compilation step is somewhat "expensive".  Zooming into the issue always revealed Lombok to be a larger contributor. Unfortunately, I can't get rid of Lombok in this customer project (before you ask).

Apparently, Lombok is printing the respective `JCTree` here and there to check for type matches. I can't imagine this to be super efficient, but that's how it is at the moment.
<img width="948" alt="image" src="https://user-images.githubusercontent.com/6304496/220134737-bd9b508c-a908-448b-b0d1-e960db28b24a.png">

Anyhow, regardless of the Lombok inefficiencies I think there are some optimization opportunities in the JDK itself. 

1. Overall, `Pretty.visitSelect` accounts for 8-10% of the total allocations in this project. And among those there are StringBuilder allocations coming from the following:


    public void visitSelect(JCFieldAccess tree) {
        try {
            printExpr(tree.selected, TreeInfo.postfixPrec);
            // StringBuilder allocations hiding in here.
            print("." + tree.name);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }


This PR splits the `print` calls into two separate ones to avoid this String concatenation.

...
            printExpr(tree.selected, TreeInfo.postfixPrec);
            print('.');
            print(tree.name);
...


Secondly, the `print` method takes an `Object` which seems like a good fit for another (private?) variant of it that only takes a `char`. By this we would probably avoid any eventual boxing and avoid any conversion with `Convert.escapeUnicode(s.toString())` that seems superfluous for chars like `.`, ` `, or any braces like `(`, `{` etc. 

This is currently a draft PR as long as the scope is not clarified. It currently only includes the necessary changes that would optimize the particular use-case. But there are more cases where e.g. the new `char` variant could be used and/or any String concatenation could be split into separate `print` calls.

Let me know what you think and if I should include the other cases as well. If you think this is worthwhile, I'd appreciate if this is is sponsored. (Including creating an issue as I can't do this myself apparently. I will of course squash everything together with the proper issue ID once available.)

I've contributed before, so the CLA should be signed.

Cheers,
Christoph

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

Commit messages:
 - 8303078: Reduce allocations when pretty printing JCTree

Changes: https://git.openjdk.org/jdk/pull/12667/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303078
  Stats: 155 lines in 1 file changed: 35 ins; 1 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/12667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12667/head:pull/12667

PR: https://git.openjdk.org/jdk/pull/12667