Odd interaction between ArrayList$Itr and Escape Analysis
Vitaly Davidovich
vitalyd at gmail.com
Mon Sep 12 20:15:41 UTC 2016
On Mon, Sep 12, 2016 at 3:56 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:
> On Mon, Sep 12, 2016 at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>>
>> It seems odd to me as well why inlining won't force load the missing
>> class(es). If we're inlining, it means the method itself or the call chain
>> it's part of is hot - failing to inline can have negative side-effects,
>> like this example. I suppose there must be a good reason why it doesn't do
>> this though?
>>
>
> That's because we can't. The JIT compilers are running on their own
> threads, and they're not real "Java threads". So they are not allowed to
> run arbitrary Java code. But Java class loading may involve running
> arbitrary Java code, e.g. the ClassLoader.loadClass() upcall.
> Force class loading can be done on the triggering side (for the top-level
> method), because compilation tasks are triggered from real Java threads,
> and they're allowed to run arbitrary Java code.
>
I see, makes sense. Perhaps there can be an option to turn on loading of
required types in the entire compilation unit, after all inlining is done
(and therefore make the unloaded types not be barriers for inlining). I'd
personally prefer that over having odd performance differences.
>
> - Kris
>
Thanks Kris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160912/60a71cac/attachment.html>
More information about the hotspot-compiler-dev
mailing list