Broken thread scheduling in indexed loop (missing safepoint?)

[Vitaly Davidovich]

Ah, good point about TLAB filling up and slow path ensuing.

Thanks for the insight.

Sent from my phone
On Nov 30, 2012 3:28 PM, "Volker Simonis" <volker.simonis at gmail.com> wrote:

> Hi Vitaly,
>
> you're right, even a STW GC will have to wait until this loop without a
> safepoint will finish. On the other side, if there is an allocation inside
> the loop, the allocation will be done on the "fast path" (without safepoint
> check) only until the thread local buffer (TLAB) will be full. After that
> it will have to take the "slow path" which is a VM call and which has a
> safe point check. So in practice I think the problem is only with very
> tight loops which do same small but expensive computations (or with nested
> int loops which have potentially the same complexity like long loops but no
> safpoint either).
>
> Regards,
> Volker
>
> On Friday, November 30, 2012, Vitaly Davidovich 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/8a123740/attachment.html