Please, extend support for the GraalVM native JVM target

[ludoch]

See some work done on
https://github.com/hpehl/quarkus-grpc-extension/blob/master/runtime/src/main/java/io/quarkus/grpc/runtime/graal/GrpcNettySubstitutions.java as an example...

If this is backed in in the library, then all users would benefit.
See googleapis/google-cloud-java#4664 for more context.

[carl-mastrangelo]

@ludoch Can you clarify what you are asking for? (also, your first link appears to be to a hidden repo, I can't see it).

[ludoch]

link is https://github.com/hpehl/quarkus-grpc-extension/blob/master/runtime/src/main/java/io/quarkus/grpc/runtime/graal/GrpcNettySubstitutions.java

It seems that Graal Vm does not support 100% of the Java APIs, as seen in https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
The code sample above is the current QuarkIO attempt to make some gprc working with it.

Repo is https://github.com/hpehl/quarkus-grpc-extension
Sample code at: https://github.com/hpehl/quarkus-grpc-quickstart

I see for example:

@TargetClass(className = "io.grpc.netty.ProtocolNegotiators")
final class Target_io_grpc_netty_ProtocolNegotiators

so this is a way to rewrite some classes so they work with Graal VM.
Not sure if these extensions should be in framewoek libs or handled by core libraries like GRPC.

A troubling line is this one:

    private static sun.misc.Unsafe getUnsafe() {
        // since we configured Netty with io.netty.noUnsafe=true, this should be safe
        return null;
    }

which may cause trouble down the line for other libraries that depend on this call not being null...
Not sure.

[ejona86]

getUnsafe isn't surprising and code should be able to handle unsafe being unavailable (although potentially be slower). Note also that that line appears to be for Protobuf's benefit, which I can believe given how it said Graal rewrites index numbers for offsets. This seems like the proper "fix".

The other piece is logSslEngineDetails, which is interesting. The change seems fine, as it basically disables the method, and that doesn't hurt much. It's unclear why it was needed, though.

There doesn't seem to be much to do here; the status-quo looks fine.

I would expect actually running to have a few more issues. For example, Netty uses finalizers, which could leak memory if they aren't being called.

[ejona86]

So I disabled the ProtocolNegotiators override and it seems to clearly show Graal is overly restrictive. It is complaining about us using instanceof to check if an instance is something it doesn't support. That would clearly be false as there would be no way to create the instance. We don't even cast to the type it doesn't like (we look at statics defined elsewhere). There's also no obvious way for us to fix this in our code.

Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: Unsupported type io.netty.handler.ssl.ReferenceCountedOpenSslEngine is reachable
To diagnose the issue, you can add the option --report-unsupported-elements-at-runtime. The unsupported element is then reported at run time when it is accessed the first time.
Trace: 
	at parsing io.grpc.netty.ProtocolNegotiators.logSslEngineDetails(ProtocolNegotiators.java:406)
Call path from entry point to io.grpc.netty.ProtocolNegotiators.logSslEngineDetails(Level, ChannelHandlerContext, String, Throwable): 
	at io.grpc.netty.ProtocolNegotiators.logSslEngineDetails(ProtocolNegotiators.java:397)
	at io.grpc.netty.ProtocolNegotiators$ServerTlsHandler.fail(ProtocolNegotiators.java:190)
	at io.grpc.netty.ProtocolNegotiators$ServerTlsHandler.exceptionCaught(ProtocolNegotiators.java:152)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:285)
	at io.netty.channel.AbstractChannelHandlerContext.access$400(AbstractChannelHandlerContext.java:38)
	at io.netty.channel.AbstractChannelHandlerContext$5.run(AbstractChannelHandlerContext.java:270)
	at com.oracle.svm.core.jdk.RuntimeSupport.executeHooks(RuntimeSupport.java:144)
	at com.oracle.svm.core.jdk.RuntimeSupport.executeStartupHooks(RuntimeSupport.java:89)
	at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:144)
	at com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
--------------------------------------------------------------------------------------------
-- WARNING: The above stack trace is not a real stack trace, it is a theoretical call tree---
-- If an interface has multiple implementations SVM will just display one potential call  ---
-- path to the interface. This is often meaningless, and what you actually need to know is---
-- the path to the constructor of the object that implements this interface.              ---
-- Quarkus has attempted to generate a more meaningful call flow analysis below          ---
---------------------------------------------------------------------------------------------

[ludoch]

Context is via hpehl/quarkus-grpc-extension#1

[hpehl]

Thanks @ejona86 for looking into this. Any improvements which make grpc-java more GraalVM friendly are of course welcome. In Quarkus one can use the @TargetClass / @Substitute annotations to workaround certain limitations. This approach works quite well for most of the limitations.

Side note: I came across two other limitations as I implemented the Quarkus gRPC extension:

1. The generated BindableService implementation defines the bindService() method as final. This makes it hard to create a dynamic proxy for CDI integration. I've found a workaround, but it would be nice to have more options regarding how the code is generated.
2. The generated code for messages depends on reflection. This is an issue in native mode. I've tried to use option optimize_for = CODE_SIZE (see https://developers.google.com/protocol-buffers/docs/reference/java-generated#message), but had issue to get it working.

[ejona86]

This makes it hard to create a dynamic proxy for CDI integration.

Could you please explain this more? You should probably create a separate issue for discussing this. We're using final on bindService() for mocks to operate properly. In other cases it caused warnings, but the final method still behaved more properly since it was final.

The generated code for messages depends on reflection.

Issues here seem like they should be directed to protobuf. Is this the fallback implementations in GeneratedMessage? Pointing out specific code that is causing trouble is helpful.

The optimize_for was bad and I thought it had mostly been removed. Java lite has a separate generated code plugin now. It looks like optimizing for CODE_SIZE uses some of the reflection fallbacks instead, which seems like the opposite of what you were hoping for.

[ejona86]

It looks like Netty has plenty of substitutions. That sort of makes me feel like using quarkus-grpc-extension is not all that bad of a way to go in the short-term. gRPC's one issue is a drop in the bucket.

I do understand how a bit more of this fits together now, and I will be interested to hear the outcome of oracle/graal#1061. I also would be interested in a way to detect if using SubstrateVM in order to avoid problematic code paths.

[hpehl]

Could you please explain this more? You should probably create a separate issue for discussing this. We're using final on bindService() for mocks to operate properly. In other cases it caused warnings, but the final method still behaved more properly since it was final.

The quarkus-grpc-extension supports CDI in gRPC services and interceptors. gRPC services and interceptors should be singletons and my first attempt to make them @ApplicationScoped failed due to final on bindService() (unable to create a dynamic proxy). There's a simple workaround to make the services and interceptors @Dependent and provide access through an @ApplicationScoped bean.

So it's not a super urgent limitation. I agree that this should be discussed in a separate issue. I filed #5471 to track this.

The optimize_for was bad and I thought it had mostly been removed. Java lite has a separate generated code plugin now. It looks like optimizing for CODE_SIZE uses some of the reflection fallbacks instead, which seems like the opposite of what you were hoping for.

Thanks for the update. I'll try to use the java lite plugin and check whether this also causes problems regarding reflection.

It looks like Netty has plenty of substitutions. That sort of makes me feel like using quarkus-grpc-extension is not all that bad of a way to go in the short-term.

That's right. The quarkus-grpc-extension depends on the netty-extension and puts only the gRPC relevant substitutions on top of the already existing Netty ones.

[viktorklang]

Also, please see the following: #6006 (comment)