Hello,
sorry for the late answer.
If you use an invoker like the MethodHandles.exactInvoker() instead of using
directly invokeExact() you will not have any stackframes from your vmPlugin.
The idea is that is to have a code like that
public static CallSite bsm(Lookup lookup, String name, MethodType type) {
return new InliningCache(type);
}
private static class InliningCache extends MutableCallSite {
private static final MethodHandle SLOW_PATH;
static {
var lookup = MethodHandles.lookup();
try {
SLOW_PATH = lookup.findVirtual(InliningCache.class, "slowPath",
methodType(MethodHandle.class, Object.class));
} catch (NoSuchMethodException | IllegalAccessException e) {
throw new AssertionError(e);
}
}
public InliningCache(MethodType type) {
super(type);
setTarget(MethodHandles.foldArguments(MethodHandles.exactInvoker(type),
SLOW_PATH.bindTo(this)));
}
private MethodHandle slowPath(Object Object receiver) {
...
}
}
so your slowpath return a method handle that is call by the exactInvoker, so
the method slowPath is not on the stack.
regards,
Rémi
----- Original Message -----
> From: "'Jochen Theodorou' via JVM Languages" <jvm-languages@googlegroups.com>
> To: "jvm-languages" <jvm-languages@googlegroups.com>
> Sent: Monday, February 5, 2024 5:38:54 PM
> Subject: [SOC][jvm-l] avoiding indy code in stack trace
> Hi all,
>
> if I have a Groovy program like this:
>
> import java.lang.StackWalker
> import static java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE
>
> StackWalker walker = StackWalker.getInstance(RETAIN_CLASS_REFERENCE)
> walker.walk (s->s.forEach(l -> println l))
>
> which does bascially the same it does in Java, which is writing out a
> bunch of stack frames the stack walker deems worth of retaining. My
> first question here would be if @Callersensitive code would actually
> take the first of these "frames" to find the caller class. Is it the
> same mechanism?
>
> I assume yes, leading to a problem if the trace looks like this:
>
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:336)
> run.run(run.groovy:5)
> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:290)
>
> run.groovy with the class "run" should be the caller class, but in this
> trace IndyInterface.fromCache appears first, leading me to assume this
> is what would be used instead.
>
> In a possible module scenario there would be a Groovy runtime module
> which contains the fromCache method, run.groovy would be maybe in a
> module A, the target method in module B. I have no problem with module A
> requires Groovy and requires B. But B would have to be open to Groovy,
> well... let's just say this develops more into bypassing the module
> system than anything else.
>
> The reason why fromCache is visible is because of the invokeExact that
> is in there calling the final handle. And this is in there because I
> need to use something to determine the target of the method call based
> on runtime types of receiver and arguments of the method call. So at
> least for the first call I am stuck with this invoke call in fromCache.
>
> Or is there a way around this and I am just to stuck to see this?
>
> bye Jochen
>
> --
> You received this message because you are subscribed to the Google Groups "JVM
> Languages" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email
> to jvm-languages+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jvm-languages/b94a0432-c072-46a8-9a66-56b255f43bbc%40gmx.org.
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jvm-languages+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jvm-languages/1824188431.13565243.1708678937573.JavaMail.zimbra%40univ-eiffel.fr.
