In some configurations, for example with lots of debugging info and --with-native-debug-symbols=internal that yields huge .so-s, jlink tests fail with:

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=tools/jpackage/ TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
...
java.lang.OutOfMemoryError: Java heap space
        at java.base/java.io.InputStream.readNBytes(InputStream.java:405)
        at java.base/java.io.InputStream.readAllBytes(InputStream.java:346)
        at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
        at jdk.jlink/jdk.tools.jlink.internal.plugins.StripNativeDebugSymbolsPlugin$StrippedDebugInfoBinaryBuilder.build(StripNativeDebugSymbolsPlugin.java:316)
        at jdk.jlink/jdk.tools.jlink.internal.plugins.StripNativeDebugSymbolsPlugin.lambda$transform$0(StripNativeDebugSymbolsPlugin.java:114)
        at jdk.jlink/jdk.tools.jlink.internal.plugins.StripNativeDebugSymbolsPlugin$$Lambda$686/0x0000000800dadc40.apply(Unknown Source)
        at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.lambda$transformAndCopy$0(ResourcePool.java:113)
        at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool$$Lambda$628/0x0000000800d94440.accept(Unknown Source)
        at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
        at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
        at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
        at jdk.jlink/jdk.tools.jlink.plugin.ResourcePool.transformAndCopy(ResourcePool.java:112)
        at jdk.jlink/jdk.tools.jlink.internal.plugins.StripNativeDebugSymbolsPlugin.transform(StripNativeDebugSymbolsPlugin.java:109)
        at jdk.jlink/jdk.tools.jlink.internal.plugins.DefaultStripDebugPlugin.transform(DefaultStripDebugPlugin.java:84)
        at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.visitResources(ImagePluginStack.java:274)
        at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:182)
        at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:161)
        at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:851)
        at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:206)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:408)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:272)
        at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
        at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:63)

It more or less reliably reproduces with Shenandoah in my builds, but it is not Shenandoah-specific.

This can be mitigated by a very simple patch that just copies the InputStream straight to destination file without instantiating the huge array.