RFR (XS): JDK-8014430: JRE crashes instead of stop compilation on full Code Cache. Internal Error (c1_Compiler.cpp:87)

[Albert Noll]

Hi,

I implemented the same behavior for C1 as there is in C2, if there is 
insufficient memory in the code cache to instantiate the compiler. I.e., 
only the interpreter is used.

However, I am not quite sure if the current patch considers all 
variables that must be set (if there are any?) when compilation is 
aborted due to insufficient memory. So please take a close look!

Many thanks,
Albert

webrev: http://cr.openjdk.java.net/~anoll/8014430/webrev.01/

On 16.05.2013 17:57, Vladimir Kozlov wrote:
> Thank you, Albert
>
> Yes, the behavior should be the same.
>
> Vladimir
>
> On 5/16/13 7:09 AM, Albert Noll wrote:
>> Hi,
>>
>> Vladimir, Christian, thanks for your feedback.
>> When -Xcomp or -server is used, hotspot starts up
>> and prints the following warning:
>>
>> Java HotSpot(TM) Server VM warning: CodeCache is full. Compiler has 
>> been disabled.
>> Java HotSpot(TM) Server VM warning: Try increasing the code cache 
>> size using -XX:ReservedCodeCacheSize=
>> CodeCache: size=1024Kb used=488Kb max_used=504Kb free=535Kb
>>   bounds [0xf5fb4000, 0xf60b1000, 0xf60b4000]
>>   total_blobs=271 nmethods=154 adapters=64
>>   compilation: disabled (not enough contiguous free space left)
>>
>>
>> I suppose that is the behavior that we should also get when starting 
>> Hotspot
>> with -client. Sorry, I did not consider that.
>>
>> Best,
>> Albert
>>
>>
>>
>>
>>
>> On 15.05.2013 18:10, Vladimir Kozlov wrote:
>>> There is an other duplicated bug assigned to Roland (serach jbs). We 
>>> should wait for him to comment on this.
>>> I think, we should not exit VM but only disable C1 compilation as we 
>>> do with C2.
>>> Albert, could you verify C2 (sever vm) behavior in such situation?
>>> Also what happens when -Xcomp is used?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/15/13 2:49 AM, Albert Noll wrote:
>>>> Hi,
>>>>
>>>> thank you for reviewing!
>>>>
>>>> Best,
>>>> Albert
>>>>
>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8014430
>>>> webrev: http://cr.openjdk.java.net/~anoll/8014430/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Eanoll/8014430/webrev.00/>
>>>>
>>>> Problem: VM failed with the following error message when the 
>>>> specified code cache
>>>> specified by -XX:ReservedCodeCacheSize=... is too small to startup 
>>>> the VM.
>>>>
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  Internal Error (c1_Compiler.cpp:87), pid=25077, tid=3856251760
>>>> #  guarantee(blob != NULL) failed: must create initial code buffer
>>>> #
>>>> # JRE version: Java(TM) SE Runtime Environment (8.0-b89) (build 
>>>> 1.8.0-ea-b89)
>>>> # Java VM: Java HotSpot(TM) Client VM (25.0-b31 mixed mode linux-x86 )
>>>> # Failed to write core dump. Core dumps have been disabled. To 
>>>> enable core dumping, try "ulimit -c unlimited" before
>>>> starting Java again
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> #http://bugreport.sun.com/bugreport/crash.jsp
>>>> #
>>>>
>>>>
>>>> Solution: replace guarantee() with  vm_exit_out_of_memory() to 
>>>> provide a
>>>> graceful shutdown of the VM if the specified size for the code 
>>>> cache is too small
>>>> to startup the VM. The error message is now as follows:
>>>>
>>>> anoll at anoll-ThinkPad-T430:/export/anoll/test$ 
>>>> /export/anoll/jdk_export-32bit/jdk1.8.0/bin/java -client
>>>> -XX:InitialCodeCacheSize=500k -XX:ReservedCodeCacheSize=1m 
>>>> MultipleClassLoaderCCFiller
>>>> #
>>>> # There is insufficient memory for the Java Runtime Environment to 
>>>> continue.
>>>> # Native memory allocation (malloc) failed to allocate 288358 bytes 
>>>> for Compiler1 temporary CodeBuffer.
>>>> # Try to increase -XX:ReservedCodeCacheSize=.
>>>>
>>>> # An error report file with more information is saved as:
>>>> # /export/anoll/test/hs_err_pid22080.log
>>>> #
>>>> # Compiler replay data is saved as:
>>>> # /export/anoll/test/replay_pid22080.log
>>>>
>>