allthingssecurity commented on code in PR #27793:
URL: https://github.com/apache/camel/pull/27793#discussion_r4267574150
##########
components/camel-wasm/src/main/java/org/apache/camel/wasm/WasiCommand.java:
##########
@@ -73,10 +91,77 @@ public final class WasiCommand {
* than the initial memory the module
declares
*/
public WasiCommand(WasmModule module, List<String> arguments, int
maxMemoryPages) {
+ this(module, arguments, maxMemoryPages, false);
+ }
+
+ /**
+ * @param module the parsed module
+ * @param arguments the program's arguments, the program
name first
+ * @param maxMemoryPages the maximum number of 64 KiB pages the
module's memory may grow to, or 0 to keep
+ * the maximum the module declares
+ * @param compile whether to translate the module to JVM
bytecode now, with the Endive runtime
+ * compiler, instead of interpreting it.
This defines classes at run time, which a
+ * GraalVM native image cannot do. A
function that is too large for a JVM method is
+ * left to the interpreter, which is
logged once, at WARN
+ * @throws IllegalArgumentException if the module is not a WASI Preview 1
command module, or maxMemoryPages is lower
+ * than the initial memory the module
declares
+ * @throws IllegalStateException if compile is set and the Endive
runtime compiler is not on the classpath, or
+ * cannot compile the module. The message
names the module by its program name (the
+ * first argument)
+ */
+ public WasiCommand(WasmModule module, List<String> arguments, int
maxMemoryPages, boolean compile) {
this.module = Objects.requireNonNull(module);
this.arguments = List.copyOf(arguments);
validate(module);
this.memoryLimits = memoryLimits(module, maxMemoryPages);
+
+ Function<Instance, Machine> factory = null;
+ boolean fallback = false;
+ if (compile) {
+ String name = this.arguments.isEmpty() ? "(no name)" :
this.arguments.get(0);
+ try {
+ try {
+ factory = RuntimeCompiler.compile(module, false);
+ } catch (WasmEngineException e) {
+ // Endive could not compile every function. When the
reason is a function that is too large for a
+ // JVM method, the module still works with that function
interpreted, so compile again with the
+ // interpreter as fallback; for any other reason this
second attempt fails as the first one did.
+ factory = RuntimeCompiler.compile(module, true);
Review Comment:
Done in 16a799c1dedf: the second compilation with the interpreter fallback
now happens only when the cause chain of the `WasmEngineException` contains
ASM's `MethodTooLargeException`, which is how Endive 1.1.0 reports an oversized
function (`Compiler.handleMethodTooLarge`, and the FAIL branch of
`compileExtraClasses`, both wrap it as the direct cause). Any other failure is
rethrown at once with the existing "cannot be compiled" message. The check
lives in the nested `RuntimeCompiler` and compares the class name, so
camel-wasm still loads and interprets without the compiler jar.
`WasiCommandTest.onlyAFunctionTooLargeForAJvmMethodIsCompiledAgainWithTheInterpreterAsFallback`
covers the check, `moduleThatCannotBeCompiledFailsWithItsName` asserts that
its unsupported-instruction failure does not qualify for a retry, and
`functionTooLargeForAJvmMethodIsInterpreted` still passes (camel-wasm suite:
133 tests, 0 failures).
_Claude Code on behalf of allthingssecurity_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
