aot compiler halts when there exists an infinite loop in clinit()

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Apr 19 16:59:02 UTC 2017


Graal do report it in some cases (JDK-8178796):

Error: Failed compilation: 
compiler.calls.common.InvokeSpecial.caller()V: 
org.graalvm.compiler.common.RetryableBailoutException: Compilation 
exceeded 300 seconds during CFG traversal

But timeout in <clinit> may be hard to catch since it is done in JVM 
runtime and not in compiler.

Also I don't know if we should spend time on your case. If an 
application depends on such class it will never be able to execute. 
Should we care about such case?

Vladimir

On 4/19/17 9:47 AM, Yuting Chen wrote:
> The compiler can itself be a jvm, :)
>
> I'd expect that some timeout messages will be reported (a quick
> patch?). I compiled some pieces of bytecode and waited for the whole
> night...
>
> Regards,
> Yuting
>
> On Wed, Apr 19, 2017 at 2:23 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> <joke-mode>
>> Assuming your hunch is correct, I would call this a feature, not a bug.
>> Isn't it better when compilation of a program loops infinitely than when the
>> program loops infinitely at runtime? :-)
>> </joke-mode>
>>
>> Regards, Peter
>>
>>
>> On 04/18/2017 03:14 AM, Yuting Chen wrote:
>>>
>>> Hi, I recently met a problem: when I tried to compile a class whose
>>> clinit method contains an infinite loop, the aotc waits and fails to
>>> response....
>>>
>>> It seems that the aotc performs some static analysis before the
>>> compilation, while the analysis may not stop (when an infinite loop is
>>> there).
>>>
>>> The bytecode is shown as follows:
>>>
>>> public class Vector1
>>>    minor version: 0
>>>    major version: 52
>>>    flags: ACC_PUBLIC, ACC_SUPER
>>> Constant pool:
>>>     #1 = Utf8               Vector1
>>>     #2 = Class              #1             // Vector1
>>>     #3 = Utf8               java/lang/Object
>>>     #4 = Class              #3             // java/lang/Object
>>>     #5 = Utf8               serialVersionUID
>>>     #6 = Utf8               J
>>>     #7 = Long               -2767605614048989439l
>>>     #9 = Utf8               <clinit>
>>>    #10 = Utf8               ()V
>>>    #11 = NameAndType        #5:#6          // serialVersionUID:J
>>>    #12 = Fieldref           #2.#11         // Vector1.serialVersionUID:J
>>>    #13 = Utf8               main
>>>    #14 = Utf8               ([Ljava/lang/String;)V
>>>    #15 = Utf8               ConstantValue
>>>    #16 = Utf8               Code
>>>    #17 = Utf8               StackMapTable
>>> {
>>>    public static {};
>>>      descriptor: ()V
>>>      flags: ACC_PUBLIC, ACC_STATIC
>>>      Code:
>>>        stack=2, locals=0, args_size=0
>>>           0: ldc2_w        #7                  // long
>>> -2767605614048989439l
>>>           3: putstatic     #12                 // Field serialVersionUID:J
>>>           6: iconst_1
>>>           7: iconst_m1
>>>           8: iadd
>>>           9: ifge          0
>>>          12: return
>>>        StackMapTable: number_of_entries = 1
>>>          frame_type = 0 /* same */
>>>
>>>    public static void main(java.lang.String[]);
>>>      descriptor: ([Ljava/lang/String;)V
>>>      flags: ACC_PUBLIC, ACC_STATIC
>>>      Code:
>>>        stack=0, locals=1, args_size=1
>>>           0: return
>>> }
>>
>>


More information about the jdk9-dev mailing list