RFR: 8325949: Create an internal utility method for creating VarHandle instances [v5]

[Per Minborg]

On Tue, 17 Sep 2024 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge branch 'master' into internal-mh-util
>  - Rename class and shorten JavaDoc
>  - Update javadoc
>  - Rename utility class
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

I've experimented a bit with using the `ConstantBoostraps::fieldVarHandle` method and here is what it looks like at a call site (example from `CompletableFuture`):


RESULT = ConstantBootstraps.fieldVarHandle(l, "result", VarHandle.class, CompletableFuture.class, Object.class);


Compared to:


RESULT = MhUtil.findVarHandle(l,  "result", Object.class);


One advantage is that we can remove two methods from the `MhUtil` class but the drawback is we need to add a lot of more parameters at the call sites. Eventually, both methods will work the same except from the exception handling. So, I think it is better to use the proposed `MhUtil` rather than `ConstantBootstraps`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2363013810