On Wed, 11 Feb 2026 20:42:50 GMT, Phil Race <[email protected]> wrote:
> For a long time I've looked at the unnecessary complexity around the code > that manages "LayoutEngines' for OpenType font layout. > > The code was written a very long time ago when it was supposed that you might > have a layout engine that could do Arabic. An unrelated one for Devanagari. > An unrelated one for Thai. An unrelated one that knew how to handle some > special font format ... > > It uses keys to look up these 'instances' thereby creating caches that > prevent GC. > It was the cause of this bug report that font instances created from streams > that were being used by layout aren't being deleted. > There is also the implication there's some 'state' to the engines, when in > fact the methods that > invoke the native code are static methods and no state is relevant. Instances > of the native engine are created and discarded as we need them in each layout > call. There's minimal overhead to this, and whatever there is, we've been > living with for a long time, and if we *were* re-using them we'd have > overhead to ensure there was only one thread using it .. which we don't have > and don't want. > > So this PR deletes various interfaces and classes with LayoutEngine in the > name, keeping only SunLayoutEngine, and making all its methods static - most > already were. > And fixes one very definite problem with the GCing of created fonts. All the in file changes make sense to me. Also built and tested this and all seems to be stable/working. ------------- Marked as reviewed by dnguyen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29680#pullrequestreview-3838789205
