On Mon, 5 May 2025 04:50:30 GMT, Chen Liang <[email protected]> wrote:
>> Credit to @lukellmann that the duplication arg handling in #24742 avoided
>> throwing exceptions but produced a wrong option. This patch fixes that and
>> removed stream usages in CaptureCallState to speed up bootstrap.
>>
>> Also, the previous patch affected the toString display of the option; I
>> added a unit test to ensure the option prints names that is user-friendly.
>>
>> Another thing I noted is `CapturableState` uses `OperatingSystem`; using
>> `valueOf` brings a performance overhead due to setups with reflection, so I
>> made this lazy. (The enum is thread safe, so we allow racy access to the
>> cache field)
>>
>> Testing: jdk/lang/foreign, tier 1-3 in progress.
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> No env to test
src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 139:
> 137: */
> 138: private static OperatingSystem initOS() {
> 139: // Called lazily, valueOf has overhead
Hello Chen, in context of this bug fix, what kind of overhead does `valueOf()`
have?
The (pre-existing) comment on this `initOS()` method sets an expectation that
it will be called from the static initializer of this `OperatingSystem` class
and thus it expects an `ExceptionInInitializerError` to be thrown by the static
initiliazer, if the operating system name isn't recognized. Any access to
`OperatingSystem` class would then have resulted in a `NoClassDefFoundError`.
With this proposed change, the callers of `OperatingSystem.current()` would now
start seeing an `IllegalArgumentException` if for any reason the operating
system name isn't recognized.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25025#discussion_r2073026614
