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

Tue May 21 10:50:21 PDT 2013

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
>>>>>>>>
>>>>>>
>>>>
>>>
>