Broken thread scheduling in indexed loop (missing safepoint?)

[Volker Simonis]

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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml',
>>> '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/783a36b7/attachment-0001.html