On Mon, 2 Mar 2026 22:14:15 GMT, Michael Strauß <[email protected]> wrote:
>> The current implementation of `Renderer.getPeerInstance()` looks up mappings >> by concatenating strings to form a combined key: >> >> peer = peerCache.get(name + "_" + unrollCount); >> >> >> This can be improved by not using strings to store the combined key, but >> using a simple `PeerCacheKey` class instead. >> The `Renderer` class then uses a single reusable `PeerCacheKey` object to >> look up mappings, making the lookup allocation-free. >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > review comment The guidelines in question are in the [Before you integrate or sponsor a PR](https://github.com/openjdk/jfx/blob/master/README-code-reviews.md#before-you-integrate-or-sponsor-a-pr) section of the code review policies. Quoting a relevant piece: > Before you integrate or sponsor the PR, ensure that the following have been > done: > > * All substantive feedback has been addressed, especially any objections from > one with a Reviewer role > * If you have pushed any changes in response to a Reviewer's substantive > comments, wait for them to re-review the latest version of your PR with those > changes (to ensure they are satisfied with the way you addressed them) As always, it's a judgment call. I reread the comments, and I don't think it was sufficiently clear that Andy's question was still outstanding, so I can easily see why Michael integrated this with the two approving reviews. Perhaps the new issue Michael filed could be expanded to include evaluating any potential reentrancy issues (preexisting or otherwise)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2091#issuecomment-4490625226
