logback / LOGBACK-1717 [Open] Reduce the memory footprint with GraalVM native image
============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1717 ============================== Issue created ------------------------------ Sébastien Deleuze created this issue on 11/Jan/23 2:16 PM Summary: Reduce the memory footprint with GraalVM native image Issue Type: Improvement Affects Versions: 1.4.5 Assignee: Logback dev list Components: Joran, logback-core Created: 11/Jan/23 2:16 PM Environment: GraalVM native image 22.3 Labels: configuration Priority: Major Reporter: Sébastien Deleuze Description: Logback XML parsing is hardly usable on native image at runtime, to solve that issue, [Spring Boot has implemented logback.xml parsing + generation of Logback model at build time|https://github.com/spring-projects/spring-boot/commit/4a76fbf93c03b45917f06c65bbd877ac160a6149], and this works well. But from a GraalVM native image static analysis point of view, XML parsing capabilities are reachable from {{GenericXMLConfigurator#doConfigure(URL)}}. In practice, that means that [675 unused classes at runtime|https://gist.github.com/sdeleuze/674b63fc9d3c265ff51877db3b8a5e7f] are compiled and shipped in the native image, increasing the footprint (RSS memory) by 2.43M for nothing. As discussed in [https://github.com/spring-projects/spring-boot/issues/33324], the Spring team would like to know if Logback could make it possible to remove such XML parsing capabilities from the reachable code path when unneeded. This method is reachable from various places, including services loaded by the service loader where we don't have any control, so the way to handle that in an elegant way is not 100% obvious. Maybe a static boolean property controlled by the detection of a logback configuration file (extracting the logic from {{DefaultJoranConfigurator#findURLOfDefaultConfigurationFile}}) could make {{GenericXMLConfigurator#doConfigure(URL)}} implementation no op or throwing an exception when XML configuration files are not present. Combined with the capability of computing some static fields at build time, that could allow us to have the desired behavior and make XML code unreachable without too much impact on Logback infrastructure. Happy to discuss other options, including first class build-time model generation if there is interest on that topic. Any thoughts? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59) _______________________________________________ logback-dev mailing list logback-dev@qos.ch https://mailman.qos.ch/cgi-bin/mailman/listinfo/logback-dev
