RFR (XS): JDK-8013496: Code cache management command line, options work only in special order. Another order of arguments does, not deliver the second parameter to the jvm.

[Vladimir Kozlov]

Chris,

We already have filed bug for such crash in C1 and we will fix it 
eventually :) :

https://jbs.oracle.com/bugs/browse/JDK-7170965

I agree that 4Mb is too much. For now we will use only check vs 
InitialCodeCacheSize (as current code does). And InitialCodeCacheSize is 
set to 160Kb for Client VM on x86. The default value is platform/VM 
specific and defined in c?_globals_<arc>.hpp.

Thanks,
Vladimir

On 5/3/13 5:00 PM, Chris Plummer wrote:
> I think 4mb is much too big. Tiered uses a lot more codecache than just
> the client VM. I can run HelloWorld in 650k:
>
> % ./java -client -XX:ReservedCodeCacheSize=650k
> -XX:CodeCacheMinimumFreeSpace=50k -XX:-UseCodeCacheFlushing
> -XX:+PrintCodeCache -XX:+PrintCodeCacheOnCompilation HelloWorld
> CodeCache: size=652Kb used=577Kb max_used=577Kb free=74Kb
> CodeCache: size=652Kb used=579Kb max_used=579Kb free=72Kb
> CodeCache: size=652Kb used=580Kb max_used=580Kb free=71Kb
> CodeCache: size=652Kb used=580Kb max_used=580Kb free=71Kb
> CodeCache: size=652Kb used=581Kb max_used=581Kb free=70Kb
> CodeCache: size=652Kb used=585Kb max_used=585Kb free=66Kb
> CodeCache: size=652Kb used=586Kb max_used=586Kb free=65Kb
> CodeCache: size=652Kb used=586Kb max_used=586Kb free=65Kb
> CodeCache: size=652Kb used=587Kb max_used=587Kb free=64Kb
> Hello world.
> CodeCache: size=652Kb used=588Kb max_used=588Kb free=64Kb
> CodeCache: size=652Kb used=588Kb max_used=588Kb free=64Kb
>   bounds [0xb7258000, 0xb72f0000, 0xb72fb000]
>   total_blobs=138 nmethods=10 adapters=64
>   compilation: enabled
>
> There are a number of factors that will determine the minimal codecache
> size that will work:
>
>   * debug or product build
>   * enabling JVMTI
>   * C1, C2, or tiered
>
> There are probably others. I'm not sure how best to manage this with
> respect to determining a minimal codecache size. However, I think the
> following should be fixed:
>
> % ./java  -client -XX:-PrintFlagsFinal -XX:-UseCodeCacheFlushing
> -XX:CodeCacheMinimumFreeSpace=50k -XX:+PrintCodeCache
> -XX:+PrintCodeCacheOnCompilation -XX:ReservedCodeCacheSize=600k HelloWorld
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (c1_Compiler.cpp:87), pid=32553, tid=2793999216
> #  guarantee(blob != NULL) failed: must create initial code buffer
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0-b88) (build
> 1.8.0-ea-b88)
> # Java VM: Java HotSpot(TM) Client VM (25.0-b30 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
> #
> # An error report file with more information is saved as:
> # /tmp/hs_err_pid32553.log
> Phoning home...
> Using server: 10.161.186.18, port 4711
> Hello world.
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.sun.com/bugreport/crash.jsp
> #
> Aborted
>
> I see two problems with this. First, it's not a very friendly way to die
> because of limited memory. Shouldn't the VM just exit with some sort of
> startup failure message. Either that or just print a message (once) and
> then continue on without attempting any further compilations. For the
> 2nd issue, noticed that "Hello world." was still printed, despite the
> apparent crash. Maybe the compiler thread crashed, and the interpreter
> thread was able to finish the job before being forced to exit.
>
> Chris
>
>
> On 5/3/13 12:00 PM, Albert Noll wrote:
>> Hi Vladimir,
>> thank you for the feedback. I tried to execute a simple "Hello World" on
>> my system.
>> - with "-Xint": 2MB are fine
>> - with "-XX:+TieredCompilation" and 2MB, hotspot crashes:
>>     #  Internal Error
>> (/export/anoll/JDK-8013496/src/share/vm/c1/c1_Compiler.cpp:87),
>> pid=23449, tid=140038076614400
>>     #  guarantee(blob != NULL) failed: must create initial code buffer
>> - with "-XX:+TieredCompilation" and 2.1MB: fine
>>
>> Interestingly, "java -Xint -XX:+TieredCompilation" is legal too. I guess
>> we should change that too.
>>
>> How about a minimum code cache size of 4MB?
>>
>> Best,
>> Albert
>>
>> On 05/03/2013 05:07 PM, Vladimir Kozlov wrote:
>>> My latest check of used codecache before JIt compilation shows that
>>> more than 1Mb was used (template interpreter, stubs, adapters). I
>>> think 1K is too small. Run (for example, on sparc) a small program
>>> with -Xint to see how much you need. Also we have and
>>> CodeCacheMinimumFreeSpace=500k parameter. So I would guess we need
>>> something around 2Mb to run VM in interpreter mode.
>>>
>>> Otherwise changes are good.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/3/13 5:54 AM, Albert Noll wrote:
>>>> Hi,
>>>>
>>>> please review the patch.
>>>>
>>>> Many thanks in advance,
>>>> Albert
>>>>
>>>> jbs:https://jbs.oracle.com/bugs/browse/JDK-8013496
>>>> webrev:http://cr.openjdk.java.net/~adlertz/JDK-8013496/webrev00/
>>>>
>>>> Problem:
>>>> The order in which the arguments  "-XX:ReservedCodeCacheSize=1m" and
>>>> "-XX:InitialCodeCacheSize=500k"
>>>> are given to hotspot mattered. In particular, the above order resulted
>>>> in an error:
>>>>
>>>> Invalid maximum code cache size: -XX:ReservedCodeCacheSize=1m. Should be
>>>> greater than InitialCodeCacheSize=2496K
>>>> Error: Could not create the Java Virtual Machine.
>>>> Error: A fatal exception has occurred. Program will exit.
>>>>
>>>> Fix: Moved the check: ReservedCodeCacheSize >= InitialCodeCacheSize to
>>>> Arguments::check_vm_args_consistency()
>>>> (as suggested in the comment).
>>>>
>>>> Currently, the minimum ReservedCodeCacheSize is 1K. Any thoughts on
>>>> that?
>>>>
>>>>
>>>>
>