gnodet-bot commented on code in PR #27793:
URL: https://github.com/apache/camel/pull/27793#discussion_r4267211153
##########
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:
⚠️ **Catch-and-retry pays full compilation cost on non-size errors**
When `compile(module, false)` throws `WasmEngineException` for a reason
other than an oversized function (e.g. malformed bytecode, unsupported
feature), `compile(module, true)` is unconditionally invoked in the catch
block. This second call runs the full compilation pipeline again — paying the
same cost — before failing with the same exception.
The comment acknowledges this ("for any other reason this second attempt
fails as the first one did"), so correctness is not affected. The impact is a
wasted compilation pass on an already-rare error path, which is acceptable. If
Endive exposes a typed exception subclass for the oversized-function case,
catching it specifically (instead of the base `WasmEngineException`) would
eliminate this cost entirely. Worth checking the Endive API.
--
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]
