RFR: 8269957: facilitate alternate impls of NameTable and Name

Archie L. Cobbs duke at openjdk.org
Tue Apr 4 19:11:23 UTC 2023

On Mon, 3 Apr 2023 20:34:07 GMT, ExE Boss <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.
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 111:
>> 109:                 return false;
>> 110:             final NameImpl that = (NameImpl)obj;
>> 111:             return that.table == table && that.string.equals(string);
> This can use `instanceof <pattern>` to match `Utf8NameTable.NameImpl::equals`:
> Suggestion:
>             return (obj instanceof NameImpl name)
>                 && table == name.table
>                 && string.equals(name.string);

Thanks. I agree the two implementations should be consistent. However you also made me realize that some common logic (e.g., type and same table checks) can be pushed up into the superclass. Also I think we should keep the initial same object check though for performance.

Refactored in c5a2546e8a5.


PR Review Comment: https://git.openjdk.org/jdk/pull/13282#discussion_r1156453422

More information about the compiler-dev mailing list