On Mon, 5 Sep 2022 13:18:08 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel >> execution of (long-running or infinite loops) user code in JShell, however >> Thread::stop is deprecated and planned for removal. >> >> Proposed patch instruments all user code to call >> LocalExecutionControl::stopCheck method before every branch instruction. >> Thread::stop call is replaced by setting global field >> LocalExecutionControl.allStop to true and stopCheck method then throws >> ThreadDead when called from the instrumented code. >> >> Proposed patch requires jdk.jshell access to java.base >> jdk.internal.org.objectweb.asm package. >> >> Please review. >> >> Thanks, >> Adam > > This is the last usage of Thread.stop in the JDK so this change is welcome. > > The instrumentation to check a flag at jump instrumentation looks reasonable, > and works here because the method is public on a public class in an exported > package. I hadn't noticed that jdk.jshell.execution is exported and the > addition to LocalExecutionControl means it's a new API so I assume forces you > to write javadoc. > > If a user presses control-C in jshell does it also interrupt the thread or > will it just set the stop flag? If it also interrupts then you have another > choice to check the interrupt status (assumes all code is well behaved of > course). > > Is there one or many LocalExecutionControl objects when I execute a snippet, > control-C, execute another? I'm wondering because the allStop flag is static > but STOP_LOCK is per instance. I think @AlanBateman proposal to monitor interrupted status is easy to implement and also does not require a new public method nor synthetic class. ------------- PR: https://git.openjdk.org/jdk/pull/10166
