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. ------------- Commit messages: - 8337853 Changes: https://git.openjdk.org/jdk/pull/29680/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29680&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337853 Stats: 219 lines in 4 files changed: 3 ins; 195 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29680/head:pull/29680 PR: https://git.openjdk.org/jdk/pull/29680
