RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
Phil Race
prr at openjdk.org
Wed Oct 18 20:08:01 UTC 2023
On Wed, 18 Oct 2023 03:43:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> > I'm unclear why it is "better". It seems more obscure to me.
>
> Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.
Not sure which "previous" that was, but in JDK 21 I did not need to specify a size.
The need to do that was something that came in as of JDK 22 and I thought it a bit of a backwards step perhaps motivated to help devs understand the sizes involved but given the arithmetic involved in general I am not sure it was justified.
>
> This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.
The previous API dealt with that just fine. And equivalently as far as I can tell.
The base offset parameter may have other uses but I need its relevance to this explained to me,
> Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.
OK, but now you have a VarHandle intended for use on a SequenceLayout (ie array) of Struct and are disguising it for some reason that isn't (sufficiently?) obvious at an API level and definitely isn't obvious at a performance level.
Is there some fundamental reason why the 21 API could not internally be reduced to the same ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1363167938
More information about the core-libs-dev
mailing list