Broken thread scheduling in indexed loop (missing safepoint?)

[Kirk Pepperdine]

OSX, didn't try on Linux

On 2012-11-30, at 9:33 PM, Volker Simonis <volker.simonis at gmail.com> wrote:

> Hi Kirk,
> 
> I can not confirm this. I've done quite some experiments with such a kind of scenario and it is true that the VM will not react on Control-C, but I could always kill the VM with kill -9. Maybe you are using a strange operating system:)
> 
> 
> On Friday, November 30, 2012, Kirk Pepperdine wrote:
> Nope.. not the problem.  GC calls for a safe point and all the thread 'cept one obey (guess which one!!!). This make the VM completely unresponsive to any signals. Strangely enough it's also apparently resistant to kill -9.. and since it's burning through CPU....
> 
> -- Kirk
> 
> On 2012-11-30, at 8:49 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
>> Haha :)
>> 
>> So it blows through Xmx, ram, and starts swapping like crazy?
>> 
>> Sent from my phone
>> 
>> On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>> We have an app that in one threads creates objects and never releases them and then in another, does a calculation in a tight loop. I would suggest if you try this you first save everything that you want to keep because when this app is run... the only way to recover is to reboot your computer.
>> 
>> It's fun!!!!
>> 
>> -- Kirk
>> 
>> On 2012-11-30, at 8:36 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>> 
>>> Hi Volker,
>>> 
>>> Just curious - what happens if a STW GC needs to occur right as this type of loop is entered? Does the VM just stall until the loop exits? What if this loop does a fast path allocation on some iteration? Do all allocations check for safepoints internally?
>>> 
>>> Thanks
>>> 
>>> Sent from my phone
>>> 
>>> On Nov 30, 2012 1:41 PM, "Volker Simonis" <volker.simonis at gmail.com> wrote:
>>> Hi,
>>> 
>>> This is a long standing problem of HotSpot (compared for example to
>>> J9). It doesn't put Safepoints into counted int loops (because it
>>> assumes they will terminate just "fast enough" which is not the case
>>> in your example). You can see another example for this behavior in
>>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29"
>>> together with the generated assembler code.
>>> 
>>> You can easily solve the problem by making your loop variable a "long"
>>> instead of an "int". In that case, HotSpot will be more cautious and
>>> place a safepoint into the loop.
>>> 
>>> Regards,
>>> Volker
>>> 
>>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk
>>> <agoncharuk at gridgain.com> wrote:
>>> > Hi,
>>> >
>>> > We faced some weird issue with thread scheduling. At a first glance it
>>> > looked like it relates to
>>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly.
>>> >
>>> > This is the code we ran:
>>> >
>>> > public static void main(String[] args) throws Exception { Thread worker =
>>> > new Thread() { @Override public void run() { double d = 0; for (int j = 1; j
>>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } };
>>> > Thread reporter = new Thread() { @Override public void run() { try { while
>>> > (true) { Thread.sleep(1000); System.out.println("Running: " +
>>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) {
>>> > Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start();
>>> > worker.join(); reporter.interrupt(); }
>>> >
>>> > One can expect that printing thread would output messages during all the
>>> > calculation time, however it hangs after 3-4 iterations. Setting
>>> > -XX:FreqInlineSize=0 as described in original bug report does not help in
>>> > this case, but if I extract loop body into a separate method, setting this
>>> > option works. Example passes with -Xint option as well. (Tested with
>>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux)
>>> >
>>> > I saw #7160161 marked as resolved, so I just wanted to confirm if behavior
>>> > we see really relates to this issue and it was fixed (bug report covers
>>> > non-Counted loop only).
>>> >
>>> > Also, is there any other workarounds rather then extracting the method and
>>> > specifying FreqInlineSize=0?
>>> >
>>> > Thanks,
>>> > Alexey Goncharuk
>>> >
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/17f3f40e/attachment.html