RFR: 8269957: facilitate alternate impls of NameTable and Name

[Jonathan Gibbons]

On Sun, 2 Apr 2023 15:06:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The `Name.Table` class is used by the compiler to hold unique instances of strings as `Name` objects.
> 
> In theory the `Name` superclass supports alternate implementations beyond the two existing implementations (`SharedNameTable` and `UnsharedNameTable`), but its current design presumes that strings are stored as UTF-8 byte arrays, which discourages other approaches.
> 
> The goal of this PR is to refactor things to allow for more flexibility in alternate `Name` implementations.
> 
> As a simple test case of this idea, it should be relatively simple to implement a `Name.Table` that stores `String`s in a hash table. This patch includes such an example in the new class `StringNameTable`, which can be enabled via the `-XDuseStringTable=true` command line flag. 
> 
> I have not done any performance testing or comparisons of `StringNameTable`; see also [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) which argues that a `String`-based implementation should be faster.
> 
> Changes:
> * Remove all byte-oriented methods from the `Name` and `Name.Table` API's, except for those that import/export Modified UTF-8.
> * Change the semantics of `Name.subName()` so the offset is a character offset, not a byte offset.
> * Consolidate the common UTF-8 machinery of `SharedNameTable` and `UnsharedNameTable` into a new common superclass `Utf8NameTable`.
> * Rename `Name.lastIndexOf()` -> `Name.lastIndexOfAscii()` to more accurately reflect its expected behavior.
> * Add new `StringNameTable` implementation.

Is it worth adding `StringNameTable` into the PR?

Is it worth putting static factory methods on `Name.Table` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1494453545
PR Comment: https://git.openjdk.org/jdk/pull/13282#issuecomment-1494455399