8353487: JShell LocalExecutionControl should allow decorating the execution task

[archiecobbs]

This PR adds the ability for subclasses of JShell's LocalExecutionControl to configure thread-local context in the execution thread that snippets execute in. Please see JDK-8353487 for more details & rationale.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Change requires CSR request JDK-8353590 to be approved
• Commit message must refer to an issue

Issues

• JDK-8353487: JShell LocalExecutionControl should allow decorating the execution task (Enhancement - P4)
• JDK-8353590: JShell LocalExecutionControl should allow decorating the execution task (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24398/head:pull/24398
$ git checkout pull/24398

Update a local copy of the PR:
$ git checkout pull/24398
$ git pull https://git.openjdk.org/jdk.git pull/24398/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24398

View PR using the GUI difftool:
$ git pr show -t 24398

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24398.diff

Using Webrev

Link to Webrev Comment

[archiecobbs]

/csr

[bridgekeeper]

👋 Welcome back acobbs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@archiecobbs an approved CSR request is already required for this pull request.

[openjdk]

@archiecobbs The following label will be automatically applied to this pull request:

• kulla

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (8c472446)
• 00: Full (68cccbf1)

[lahodaj]

I wonder how generic are the snippets used - for some types of snippets, it might be possible to put some code around the original snippet directly in the snippet. That would alleviate the need to add a new API. But presumably it would only work for some types of snippets.

For the API itself - just an idea, would having a method doInvoke along these lines work:

public Object doInvoke(Method m) throws Exception {
    return doitMethod.invoke(null, new Object[0]);
}

?

[archiecobbs]

I wonder how generic are the snippets used - for some types of snippets, it might be possible to put some code around the original snippet directly in the snippet. That would alleviate the need to add a new API. But presumably it would only work for some types of snippets.

Yes, sort of - it's already possible to modify the snippet bytecode itself of course because the ExecutionProvider is who loads it. That works for things like imposing time limits, etc., but it doesn't work so well for "wrapping" the execution because (a) you have to know what the secret method is that is going to be invoked (not hard - it's called do_it(), but kludgey), and (b) you would have to insert an INVOKESTATIC that calls into your ExecutionProvider, which means your ExecutionProvider must be available via the class loader that the snippet uses, and this is not guaranteed.

For the API itself - just an idea, would having a method doInvoke along these lines work:

public Object doInvoke(Method m) throws Exception {
    return doitMethod.invoke(null, new Object[0]);
}

Yes that would work just as well. A third option would be to define a pair like executionStart() and executionFinish().

I think your idea of a doInvoke() is actually a bit simpler/better, so I've updated that in 8c47244 and also updated the CSR.

Thanks for taking a look.

[bridgekeeper]

@archiecobbs This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[xxDark]

import jdk.jshell.execution.LocalExecutionControl;

import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class LocalExecutionControlTest {

    public static void main(String[] args) throws Throwable {
        var control = new LocalExecutionControl((ClassLoader) null) {
            Object result;

            @Override
            protected Object doInvoke(Method method) throws IllegalAccessException, InvocationTargetException {
                return result = super.doInvoke(method);
            }
        };
        control.doInvoke(MethodHandles.class.getDeclaredMethod("lookup"));
        var lookup = (MethodHandles.Lookup) control.result;
        var unsafeClass = Class.forName("jdk.internal.misc.Unsafe");
        var unsafe = lookup.findStatic(unsafeClass, "getUnsafe", MethodType.methodType(unsafeClass)).invoke();
        var field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
        lookup = (MethodHandles.Lookup) lookup.findVirtual(unsafeClass, "getReference", MethodType.methodType(Object.class, Object.class, long.class))
                .invoke(
                        unsafe,
                        lookup.findVirtual(unsafeClass, "staticFieldBase", MethodType.methodType(Object.class, Field.class)).invoke(unsafe, field),
                        (long) lookup.findVirtual(unsafeClass, "staticFieldOffset", MethodType.methodType(long.class, Field.class)).invoke(unsafe, field)
                );
        System.out.println(lookup);
    }
}

jdk/src/java.base/share/classes/module-info.java

Lines 204 to 222 in 3acfa9e

	exports jdk.internal.misc to
	java.desktop,
	java.logging,
	java.management,
	java.naming,
	java.net.http,
	java.rmi,
	java.security.jgss,
	jdk.attach,
	jdk.charsets,
	jdk.compiler,
	jdk.crypto.cryptoki,
	jdk.incubator.vector,
	jdk.jfr,
	jdk.jshell,
	jdk.nio.mapmode,
	jdk.unsupported,
	jdk.internal.vm.ci,
	jdk.graal.compiler;

Please reconsider use of reflection (or method handles)
I was looking into jshell before to achieve something like this using

jdk/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java

Line 125 in 3acfa9e

String result = invoke(doitMethod);

that exposes accessible java.lang.reflect.Method to user code, but it was not possible to get back the invocation result. With this PR, it is now possible.

[archiecobbs]

that exposes accessible java.lang.reflect.Method to user code, but it was not possible to get back the invocation result. With this PR, it is now possible.

Good point. I believe my original patch which adds a protected Runnable decorateExecution(Runnable) method instead did not have this issue, so we could just revert to that approach.

Or there is the other approach (previously mentioned) which adds executionStart() and executionFinish() methods and should also be safe.

@lahodaj what's your opinion here?

Thanks.

[bridgekeeper]

@archiecobbs This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[archiecobbs]

/touch

[openjdk]

@archiecobbs The pull request is being re-evaluated and the inactivity timeout has been reset.