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

Wed May 22 14:16:24 PDT 2013

On May 21, 2013, at 7:41 AM, Albert Noll <albert.noll at oracle.com> 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/

That looks good.  -- Chris

> 
> 
> 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/20130522/9b899ba1/attachment.html 