JDK-8023056 : use C++ exceptions for out of memory situations in the compilers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9,10
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2013-08-14
  • Updated: 2017-04-07
  • Resolved: 2017-04-07
Related Reports
Relates :  
JDK-8016057 - OOME crash in tests
Relates :  
JDK-8071534 - assert(!failing()) failed: Must not have pending failure. Reason is: out of memory
Description
Handling out of memory errors in the compiler can be cumbersome because there are so many places to check for null return values.  One possibility to make this easier would be to use C++ exceptions.

Right now HotSpot doesn't use C++ exceptions at all.  This stems from the fact that C++ compilers weren't good enough (like 15-20 years ago) to handle C++ exceptions on all platforms.  This has changed.

Since HotSpot uses it's own exception throwing mechanism to throw Java exceptions it's very likely not possible to use C++ exception everywhere.  Fortunately compilers are well abstracted from the rest of the system and we could use C++ exception only in these modules.
Comments
😢
15-03-2017
While the blog has a point it doesn't really apply to our use case in the compiler. For example the poster is talking about having too many different exception types and too much handling code. In our case it would be just one exception type (OOM) and one catch to throw away the whole compilation task.
10-03-2014
Not everybody is happy with the result of using c++ exceptions; or at least there's more to it than just blindly using them (but I think we know that). http://250bpm.com/blog:4 Cheers, Mikael
10-03-2014
Can you elaborate a bit on what you mean by "better code hygiene"?
08-02-2014
I still don't fully trust C++ exceptions to have similar behaviour on different compilers, even though its 2014. Return values would be safer and is better code hygiene anyway.
07-02-2014
Oh, interesting. I didn't know you were already thinking about this. Did you look at the attached patch? I think we can keep the OOM C++ exceptions in the compiler if we use AllocFailStrategy::EXCEPTION only in compiler code. Reviewers of other parts of the VM would need to enforce this (or we could use a define or something). Niclas has some numbers about the code size increase. I'm curious about: (a) if we could compile only parts of the code with exceptions turned on like the compiler and the runtime system but not e.g. the GCs, JVMTI, ... (b) if using C++ exceptions and getting rid of explicit error handling code makes the code size increase tolerable About RTTI, no, it's still turned off.
09-09-2013
All new operators are nothrow now.
06-09-2013
Thanks for adding me to the watch list for this. I didn't know you were thinking about this (until David told me in IM). I'm glad there is a place to discuss it. I've thought about using C++ exceptions for OOM situations in the past, especially in the context of the compiler. I think it's workable if there's a careful boundary between where we use CHECK and use C++ exceptions. Compiler code is technically native code. The purpose of CHECK etc was to bail out the JVM and throw Java exceptions back to the Java application, which doesn't make sense for the compiler. The extra generated code/space with C++ exceptions might be an issue. Does enabling exceptions make you turn on RTTI, which adds extra slots to the C++ vtable? So we've been careful to add noexcept (or empty throw() specifications on new operators). We have to make sure the code calls the right new operators if some are known to throw exceptions. I've linked that bug.
06-09-2013
Coleen, Karen, could we have your input on this topic? I know this is a delicate topic and presumably you are not very happy with this but let's have a discussion about this anyway. Using OOM exceptions in the compilers (C1 and C2) would bring down code complexity as we could get rid of the explicit return-value checks. Also with the machinery we have in place right now it's very easy to miss one allocation site and that means we are back to square one. Compilers should not bring down the whole JVM just because they try to compile a humongous method.
06-09-2013
I give you that :-) I think the problem is that guarantees were used in C2 (and perhaps C1) where actually bailouts should be. But since our bailout mechanism is so cumbersome people went for the easier guarantee route. I can't blame them. From this point of view I think having exceptions would be better. Even code complexity wise.
15-08-2013
I stand by what I said. If you can replace a guarantee with an exception because you can recover then it really wasn't a situation that warranted a guarantee in the first place. :) YMMV.
15-08-2013
You have to think compiler here; not VM. We have guarantees in the compiler which verify e.g. that the graph is correct or the register allocator didn't mess up. These are all exceptional behaviors and you can easily recover from them without affecting the VM's state. Compilers are just a module of the VM; you can live without them (or their compiled output).
15-08-2013
I would argue that if you can replace a guarantee with an exception then what you are checking should not be a guarantee in the first place. Guarantee should relate to VM state and if you find it false then it means your VM is broken so throwing an exception would only add fuel to the fire.
15-08-2013
Generally I agree with David that it will take some time to get it working. I disagree on the little benefit part. In the compiler context we can use C++ exceptions for much more than just OOM recovery. All guarantees that are in C1 and C2 right now could be replaced with exceptions that record the problem but don't bring down the whole VM. This is exactly what you want in a production environment. On the other hand we could just wait until we have a compiler that is written in Java and we get all that from the beginning. For free :-)
15-08-2013
This is definitely a future project that requires a lot of bake time. Hotspot not only doesn't use C++ exception it KNOWS that it doesn't - in general I would expect huge problems trying to introduce them - and for little benefit. Constraining to well defined subsystems/call-paths may be feasible, but there would still be a lot of work to make sure the code is exception-safe.
15-08-2013
Also need to check change in compilation time.
14-08-2013
The attached patch enables C++ exceptions for all HotSpot files. Usually this increases the size of the binary. I have not verified the sizes yet so someone should do this.
14-08-2013
Attached is a proof-of-concept that adds another AllocFailStrategy which can be used in allocations done in the compilers.
14-08-2013