GraalVM wishlist

[ppkarwasz]

Since log4j-api and log4j-core heavily rely on reflection, GraalVM users need to provide a lot of reachability metadata in their applications.

Right now there are already tools that help users in compiling this metadata:

• there is a Tracing Agent that generates reachability metadata that can be used to compile a native application,
• there is a central repository for reachability metadata for commonly used libraries (cf. graalvm-reachability-metadata).

These tools are blunt instruments and they add to the binary code generated by GraalVM all the possible components that a user can employ in a Log4j Core configuration. This behavior eliminates one of the main advantages of Log4j Core's architecture: Log4j Core is modular, therefore it is possible for users to cherry pick the list of components that they want to use in their native application and remove the rest of the code.

The big question is how to choose this list of components? I am opening this discussion to allow users to express their expectation regarding the usage of Log4j Core in a native application:

• do you want your native application to be able to interpret any configuration file? This will allow you to change the configuration file without having to recompile your application.
• are you only interested in a specific configuration file that will be hardcoded in the application? This option will reduce the size of the native application.
• do you want to manually choose the list of plugins included in your native application?

[isarang]

First of all, thanks for taking up this initiative!

Can we not include the reflection/reachability metadata in the module itself?
if the module is part of build, the metadata will be loaded from module jar.

[ppkarwasz]

@isarang,

Can we not include the reflection/reachability metadata in the module itself? if the module is part of build, the metadata will be loaded from module jar.

Sure, we can include META-INF/native descriptors (cf. GraalVM documentation) in the log4j-core JAR. The log4j-api JAR after #2392 does not need any meta-data.

However this meta-data would have to list all the Log4j Core plugins (more than 300) and your native image will contain components such as Cassandra, Kafka or rolling file appender and will be quite big. I am not sure if these are needed in a native application.

Do you know if GraalVM allows to override the descriptors included in a JAR file? If this is possible we could include everything by default and offer some mechanism to size it down.

We could also do not include any descriptors by default, but offer a code generator that binds the required components. @jvz what do you think?

[mzeijen]

IMHO, getting GraalVM support to work at all should be the main priority to start with. Optimising its footprint can be done later.

The question here is how much of an issue there actually is if all the reachability metadata is include in the core library. How much does this actually increase the size of the compiled binary. If this is just a couple of MB's then this probably should not really be a practical problem. However if this means that a simple the application becomes significantly bigger (tens of MB's) then I think it is worth searching for a solution.

If you do want to split up the native reachability information from the start then I propose creating separate "native" Maven modules for the plugins in the core module. So these modules only contain the GraalVM reachability metadata of the plugins in the core dependency. Then the user has the option to add those native modules as dependencies for the plugins they are using. As this is quite cumbersome, and if the developer doesn't care that much about the native image size, then you can also provide an additional module that has dependencies on every "native" Maven module. That way the developer gets it all in one go.

[jvz]

If we're adding reachability metadata to 2.x, then yeah, it'd have to contain all of it. A code generator to bind required components could be more ideal (at least for 3.x), though that would require that all injection points into plugins are public. In that case, we could generate some sort of helper classes for each plugin that provide lambdas for statically referencing the injection points. Some sort of inspiration might be useful from a static DI framework like https://avaje.io or similar.

Realistically, the reachability metadata is probably the easier approach to start with. We could generate the metadata through an annotation processor at the very least.

[ppkarwasz]

Note: the reachability meta-data does not have to be included in the JAR, it can be submitted to oracle/graalvm-reachability-metadata. The only reason that Logback (and even Log4j 1.2.17!) work with GraalVM is that someone outside the dev team submitted data there.

Realistically, the reachability metadata is probably the easier approach to start with. We could generate the metadata through an annotation processor at the very least.

Yes, log4j-docgen and log4j-plugin-processor can easily do it at each build. The log4j-docgen is probably the easiest to adapt: it already generates the names and all the properties of the plugins and stores them in an XML descriptor. We only need to add to the descriptor the names of the builder methods and fields.

[jvz]

Oh yeah, the docgen tooling would be ideal here! These are simply more generated model files after all.

[mzeijen]

Providing GraalVM support is not only going to be about providing reflection/reachability metadata, but also might require rewriting parts of Log4j that GraalVM does not agree with (and reflection/reachability metedata can't fix) or to provide substitution code that replaces these parts when using GraalVM.

I indicate this because I encountered such a case while implementating GraalVM support for the log4j-api for a GraalVM test application. When starting a GraalVM compiled native binary, it failed to initialise Log4J because of the ServiceLoaderUtil.callServiceLoader method, which uses some feature of Java that is not supported by GraalVM, or behaves differently within GraalVM so that it doesn't work anymore. I don't know the details anymore, but you will probably encounter it quickly when trying to get GraalVM working for the Log4j API. The workaround I applied is to use the GraalVM substitute feature to replace the problematic callServiceLoader method with my own more basic implementation. This is the substitution code for reference:

import java.lang.invoke.MethodHandles.Lookup;
import java.util.Collections;
import java.util.ServiceLoader;

import com.oracle.svm.core.annotate.Substitute;
import com.oracle.svm.core.annotate.TargetClass;
import org.apache.logging.log4j.status.StatusLogger;

/**
 * This class should be considered internal.
 */
@TargetClass(org.apache.logging.log4j.util.ServiceLoaderUtil.class)
public final class Log4jUtilServiceLoaderUtil {

    @Substitute
    static <T> Iterable<T> callServiceLoader(Lookup lookup, Class<T> serviceType, ClassLoader classLoader,
                                             boolean verbose) {
        System.out.println("Loading with service loader: " + serviceType);
        try {
            return ServiceLoader.load(serviceType, classLoader);
        } catch (Throwable e) {
            if (verbose) {
                StatusLogger.getLogger().error("Unable to load services for service {}", serviceType, e);
            }
        }
        return Collections.emptyList();
    }

}

[ppkarwasz]

@mzeijen

When starting a GraalVM compiled native binary, it failed to initialise Log4J because of the ServiceLoaderUtil.callServiceLoader method, which uses some feature of Java that is not supported by GraalVM, or behaves differently within GraalVM so that it doesn't work anymore.

This was fixed in #2392 and is available in our 2.24.0-SNAPSHOT (see Snapshot Builds for the location of our snapshot repository).

[mzeijen]

Thanks for letting me know. Hopefully you don't encounter any other similar issues.