RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
Peter Levart
peter.levart at gmail.com
Fri May 10 13:15:12 UTC 2013
Hi again,
While the below patch works and keeps Reference Handler running in all
scenarios, the evaluation exposed a weakness of JVM. If loading of a
class fails because of OOME, this class can not be used in this
incarnation of the VM even if OOME was just a transient condition.
Regards, Peter
On 05/10/2013 01:21 PM, Peter Levart wrote:
> On 05/10/2013 12:52 PM, Peter Levart wrote:
>> While executing the above test with the patch to ReferenceHandler
>> applied, I noticed a strange behaviour. I can reproduce this
>> behaviour reliably on both JDK7 and JDK8. When the patch is applied
>> as proposed:
>>
>> try {
>> lock.wait();
>> } catch (InterruptedException |
>> OutOfMemoryError x) { }
>>
>> ... I still get the following output from the test (reliably, always):
>>
>> Exception: java.lang.OutOfMemoryError thrown from the
>> UncaughtExceptionHandler in thread "Reference Handler"
>> Exception in thread "main" java.lang.Exception: Reference Handler
>> thread died.
>> at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:80)
>>
>> But when i change the patch to the following:
>>
>> try {
>> lock.wait();
>> } catch (OutOfMemoryError |
>> InterruptedException x) { }
>>
>> ...the test reliably and always passes.
>>
>> My explanation to his behaviour is that the order of exception
>> handlers changes the order of class referencing. In the former
>> variation (that still throws OOME) the following seems to be happening:
>>
>> wait() is interrupted and InterruptedException instance creation is
>> attempted. Because this is the 1st reference to InterruptedException
>> class in the lifetime of the JVM, loading of InterruptedException
>> class is attempted which fails because of OOME. This OOME is caught
>> by handler and ignored. But after handling of this OOME, another
>> reference to InterruptedException class is attempted by exception
>> handlers themselves (I don't know how exception handlers work
>> exactly, but I have a feeling this is happening). Because
>> InterruptedException class was not successfully loaded the 1st time
>> tried, every reference to this class must throw NoClassDefFoundError,
>> so this is attempted, but creation of NoClassDefFoundError fails
>> because there's no heap space and another OOME is thrown - this time
>> out of exception handling block, which is propagated and kills the
>> thread.
>>
>> If the order of exception handlers is reversed, this second OOME is
>> caught and ignored.
>
> Hi,
>
> This really seems to be happening (at least approximately, see below)
> because if InterruptedException class is preloaded at start of test,
> the order of exception handling does not have any impact on test.
>
> By disassembling the class-files of both variants, I found the only
> difference is the order of OutOfMemoryError & InterruptedException
> entries found in exception table:
>
> catch (InterruptedException | OutOfMemoryError x) variant has:
>
> public void run();
> Code:
> 0: invokestatic #2 // Method
> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;
> 3: dup
> 4: astore_2
> 5: monitorenter
> 6: invokestatic #3 // Method
> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference;
> 9: ifnull 33
> 12: invokestatic #3 // Method
> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference;
> 15: astore_1
> 16: aload_1
> 17: invokestatic #4 // Method
> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference;
> 20: invokestatic #5 // Method
> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference;
> 23: pop
> 24: aload_1
> 25: aconst_null
> 26: invokestatic #6 // Method
> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference;
> 29: pop
> 30: goto 48
> * 33: invokestatic #2 // Method
> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock;**
> ** 36: invokevirtual #7 // Method
> java/lang/Object.wait:()V**
> ** 39: goto 43*
> 42: astore_3
> 43: aload_2
> 44: monitorexit
> 45: goto 0
> 48: aload_2
> 49: monitorexit
> 50: goto 60
> 53: astore 4
> 55: aload_2
> 56: monitorexit
> 57: aload 4
> 59: athrow
> 60: aload_1
> 61: instanceof #10 // class sun/misc/Cleaner
> 64: ifeq 77
> 67: aload_1
> 68: checkcast #10 // class sun/misc/Cleaner
> 71: invokevirtual #11 // Method
> sun/misc/Cleaner.clean:()V
> 74: goto 0
> 77: aload_1
> 78: getfield #12 // Field
> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue;
> 81: astore_2
> 82: aload_2
> 83: getstatic #13 // Field
> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue;
> 86: if_acmpeq 95
> 89: aload_2
> 90: aload_1
> 91: invokevirtual #14 // Method
> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z
> 94: pop
> 95: goto 0
> Exception table:
> from to target type
> * 33 39 42 Class java/lang/InterruptedException**
> ** 33 39 42 Class java/lang/OutOfMemoryError*
> 6 45 53 any
> 48 50 53 any
> 53 57 53 any
>
> catch (OutOfMemoryError | InterruptedException x) variant has the
> exactly same bytecodes but the following exception table:
>
> Exception table:
> from to target type
> * 33 39 42 Class java/lang/OutOfMemoryError**
> ** 33 39 42 Class java/lang/InterruptedException*
> 6 45 53 any
> 48 50 53 any
> 53 57 53 any
>
>
> ... so what seems to be happening is a little different but similar to
> what I have explained. In the former variant (that still throws OOME),
> the handler 1st checks for the type of thrown exception against
> InterruptedException class, which fails and attempts to throw
> NoClassDefFoundError which can't be allocated so another OOME is
> thrown, but in the later variant the 1st check is against
> OutOfMemoryError class which succeeds, so the empty handler is
> executed and no more checks are made (no 2nd reference to
> InterruptedException class).
>
> The fix I proposed in previous mail works (OOME is thrown twice and
> 2nd OOME is handled), but also the following would work (if the order
> of checks follows the source in every compiler):
>
>
> try {
> lock.wait();
> } catch (OutOfMemoryError x) { }
> catch (InterruptedException x) { }
>
>
> ...the benefit of this is that OOME is never thrown two times.
>
> Regards, Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130510/0484a3fb/attachment.htm>
More information about the hotspot-gc-dev
mailing list