Hi, On Sat, 2022-07-09 at 09:28 -0700, Eric Norman wrote: > I'd probably try to get rid of that buffer variable and just use > java.nio.file.Files#copy to copy the inputstream to the target path.
That is a good idea. Unfortunately, we still target Java 8 with the feature launcher and the java.nio.file.Files#copy and java.io.InputStream#transferTo method used behind the scenes have only been added in Java 9. I'll start off with a minimal change which only creates the buffer when feature archives are used [1] and then we can iterate. Thanks, Robert [1]: https://issues.apache.org/jira/browse/SLING-11462 > > Regards, > -Eric > > On Sat, Jul 9, 2022 at 6:28 AM Robert Munteanu > <[email protected]> > wrote: > > > Hi, > > > > I was trying to run a feature model based application with slightly > > less memory that usual and noticed that it failed outright when I > > tried > > to launch it with 256MiB of RAM. The heap dump was very very small, > > so > > when trying to trace back the problem I noticed that the feature > > launcher uses a 256MiB byte array at [1] for reading feature > > archive > > files. It's a local variable so it does not leak, but it does > > impose a > > hard limit on the memory size. > > > > Is this something that is done intentionally? I think that for more > > light-weight applications that don't consume a lot of heap at > > runtime > > this allocation is too aggresive. If we want to keep this size ( > > although maybe we wanted 256 KiB? ) we can at least allocate it on- > > demand the first time when reading a feature archive. > > > > As a data point, I can run the Starter just fine on my laptop with > > a > > 280MiB heap. > > > > Thoughts? > > > > Thanks, > > Robert > > > > [1]: > > > > https://github.com/apache/sling-org-apache-sling-feature-launcher/blob/36b7fe229780b06f81db0a97f2e8e86726a3158c/src/main/java/org/apache/sling/feature/launcher/impl/FeatureProcessor.java#L111 > >
