Broken thread scheduling in indexed loop (missing safepoint?)

[Vitaly Davidovich]

Right, I'd also think the OS could kill it hence I thought the machine
became unusable due to heavy swapping.

Sent from my phone
On Nov 30, 2012 3: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/b1fe02a5/attachment-0001.html