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

[Albert Noll]

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/


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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130521/687ac2f5/attachment-0001.html