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. @prsadhuk need you to review this one ------------- PR Comment: https://git.openjdk.org/jdk/pull/29680#issuecomment-3938135965
