Re: speed of invokeExact

Am 10.05.2013 02:40, schrieb Christian Thalinger: [...] > That's because your method handle is not constant and so the compiler cannot > inline the call. And you tell me that in the first case the call was inlined? That is unexpected. And if that is the case, then why does this: >>> Met

Re: speed of invokeExact

Am 10.05.2013 02:40, schrieb Christian Thalinger: [...] > That's because your method handle is not constant and so the compiler cannot > inline the call. If I change the test to (using 1.8.0): > Object[] os = {"str", 1, new ArrayList(), new Object()}; > MethodType invokeType = Met

Improving the speed of Thread interrupt checking

This isn't strictly language-related, but I thought I'd post here before I start pinging hotspot folks directly... We are looking at adding interrupt checking to our regex engine, Joni, so that long-running (or never-terminating) expressions could be terminated early. To do this we're using Thread

Re: Improving the speed of Thread interrupt checking

Charles, Why bother even using CAS? Thread A is monitoring Thread B. Thread B cooperatively checks to see if it should die. Therefore, you only need B to know when A has told it to shut down. Therefore, all you need is a volatile boolean. A volatile boolean is very much faster than a full CAS o

idea: MethodHandle#invokeTailCall

Many of us would like full tail-call support in the JVM, but it of course not as trivial a change as one would like. The "clean" solution is to add a new bytecode (or perhaps multiple bytecodes for virtual, static, etc), which is a Big Deal, plus is difficult to invoke from Java. Adding switches o

Re: idea: MethodHandle#invokeTailCall

Interesting idea...comments below. On Fri, May 10, 2013 at 12:44 PM, Per Bothner wrote: > So this idea come to me: Could we just have add a method > that tail-calls a MethodHandle? Maybe some variant of >MethodHandle#invokeAsTailCall(Object... ) > This doesn't require instruction-set or cla

Re: Improving the speed of Thread interrupt checking

You need CAS because one form of the interrupt check clears it and another does not. So the get + check + set of interrupt status needs to be atomic, or another thread could jump in and change it during that process. If it were just being read, then sure...it could simply be volatile. But since th

Re: Improving the speed of Thread interrupt checking

On 05/10/2013 06:03 PM, Charles Oliver Nutter wrote: > This isn't strictly language-related, but I thought I'd post here > before I start pinging hotspot folks directly... > > We are looking at adding interrupt checking to our regex engine, Joni, > so that long-running (or never-terminating) expr

Re: Improving the speed of Thread interrupt checking

How would you handle the following with just CAS: 1) thread A reads the status and notices that it's set, and then gets preemepted 2) thread B resets the interrupt and then sets it again 3) thread A resumes and does a CAS expecting the current state to be interrupted, which it is - CAS succeeds and

Re: idea: MethodHandle#invokeTailCall

On 05/10/2013 01:32 PM, Charles Oliver Nutter wrote: > Interesting idea...comments below. > > On Fri, May 10, 2013 at 12:44 PM, Per Bothner > wrote: > > So this idea come to me: Could we just have add a method > that tail-calls a MethodHandle? Maybe some variant o

Re: Improving the speed of Thread interrupt checking

For your ABA case, I can think of a couple options: * instead of get, do getAndSet when clearing. Whether it is true or false, it will end up false, so clearing is not a big deal. However, we're always doing the write then, so perhaps... * CAS(true, false) instead of just reading. If set, it will

Re: Improving the speed of Thread interrupt checking

SwitchPoint is indeed an option, and I have used it in JRuby's compiler to reduce the frequency of checking for interrupt events. However in this case it is just a plain old library written in plain old Java that supports Java 6+. Using Indy stuff isn't really an option. Plus...it doesn't solve t

Re: Improving the speed of Thread interrupt checking

Charles, Thanks for the explanation. I have recently (for the last 6 months) been involved with some very performance centric multi-threaded work in profiling the JVM. Using JVMTI as a profiling tool with C++ underneath. The code all uses JVM locks where locks are required - but as profilers need