On Thu, 9 Oct 2025 03:01:03 GMT, Kim Barrett <[email protected]> wrote:
>> doc/hotspot-style.md line 1971: >> >>> 1969: >>> 1970: * `<system_error>` >>> 1971: >> >> To continue the roll of rationale, for `chrono` etc., here are some >> suggestions which I am just pulling out of my back pocket: >> >> "HotSpot has its own timing support APIs." >> "Initializer lists are an advanced C++ API feature which have surprising >> interactions with other initialization syntaxes in use in HotSpot." >> "HotSpot uses floating point numbers, which are more portable and have more >> predictable performance characteristics than rational arithmetic." >> "HotSpot has its own mechanisms for managing errors." > > I'll add some stuff to the PR change. > >> "HotSpot has its own timing support APIs." > > The argument for chrono is that our existing APIs aren't serving us well. > chrono provides strong type safety. We've had multiple cases of mistakes like > a double seconds being treated as double millis or vice versa, and other > similar errors. But it would be a large effort to adopt chrono. And we'd need > to decide whether to use the predefined clocks or hook up chrono to our > clocks. It may be that using the predefined clocks is fine, but it's a > question that needs careful study. > >> "Initializer lists are an advanced C++ API feature which have surprising >> interactions with other initialization syntaxes in use in HotSpot." > > I think the trailing "in use in HotSpot" can be dropped from that. Mostly I > think they are fine, but the potential ambiguity between some forms of direct > initialization and initializer list initialization, and the resolution of that > ambiguity, is unfortunate. > >> "HotSpot uses floating point numbers ..." > > Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also > fixed (though parameterized) precision. It's not a general purpose rational > arithmetic facility. My understanding is that it started life as a detail of > chrono, and was extracted and promoted to a public facility in the belief that > it has broader utility. > >> "HotSpot has its own mechanisms for managing errors." > > Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc > mechanisms. There's a bunch of discussion happening around that topic lately. > I don't think we've coalesced around any particular approach yet. And even > once we decided on something it's likely to take quite a while for rollout to > really make use of whatever we settle on. I love a good nerd sniping! Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2421306579
