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

[Albert Noll]

Hi,

Valdimir, thanks for your comments. I guess we need a second review for 
the adapted
version before we can push?

  Best,
Albert

On 21.05.2013 19:50, Vladimir Kozlov wrote:
> On 5/21/13 7:41 AM, Albert Noll wrote:
>> Hi,
>>
>> vladimir, Christian, thanks for looking at the code. I fixed the type
>> error as
>> well as another bug that was in the previous version/
>>
>> http://cr.openjdk.java.net/~anoll/8014430/webrev.01///
>> /
>> In the previous version:
>>
>>   CompilerThread::current()->set_buffer_blob(buffer_blob);
>>
>> used "buffer_blob" instead of "blob".
>>
>> Please see the new version at:
>> http://cr.openjdk.java.net/~anoll/8014430/webrev.02/
>
> It is good. (Change Copyright year).
>
>>
>> I also looked at other places where C1 allocates memory from the code
>> buffer. I found
>> a place in void Runtime1::generate_blob_for(). The current code uses
>> asserts to check
>> the the allocation works.
>>
>> Do you think we should change anything about that?
>
> C2 does the same for the same code so leave it as it is.
> I was concern about places in C1 where it may allocate other temp 
> buffers. But it looks like there are non since you and I can't find it.
>
> thanks,
> Vladimir
>
>>
>> Best,
>> Albert
>>
>>
>> On 17.05.2013 19:24, Vladimir Kozlov wrote:
>>> Albert,
>>>
>>> I assigned 7170965 to you. Close it if it is duplicate (which is, I
>>> think). But there is no mach info there (no call stack).
>>>
>>> Could you check all places in C1 which may ask for allocation in
>>> codecache?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/17/13 10:05 AM, Christian Thalinger wrote:
>>>>
>>>> On May 17, 2013, at 6:21 AM, Albert Noll <albert.noll at oracle.com> 
>>>> wrote:
>>>>
>>>>> 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/
>>>>
>>>> src/share/vm/c1/c1_Compiler.cpp:
>>>>
>>>>    97     env->record_failure("Full CacheCache\n");
>>>>
>>>> Typo.  In fact, can we use the same failure message as C2?
>>>>
>>>>      C->record_failure("CodeCache is full");
>>>>
>>>> Otherwise this looks good to me.
>>>>
>>>> -- Chris
>>>>
>>>>>
>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>