RFR: 8348858: [leyden] Bump the default code buffer sizes to store more generated code

[Vladimir Kozlov]

On Wed, 29 Jan 2025 18:57:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. I tried to address that directly, but I think relocations disagree with the whole thing, so this implementation limitation stays for a bit longer. I turned the bailout due to that cause from `info` into `warning`.
>> 
>> On `JavacBenchApp 50`, this causes us to lose 700 (!) C2 compiled methods from the SCC! We can dodge significant part of the hit by bumping the default code buffer sizes, and thus making buffers less likely to require resizing, and thus allowing to store more code in SCC. Also needs [JDK-8348855](https://bugs.openjdk.org/browse/JDK-8348855) from mainline to work well with G1. Current PR includes it, and I will upstream it separately first.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> src/hotspot/share/opto/output.cpp line 1368:
> 
>> 1366:   // the insn section, and should be counted in code_req.
>> 1367:   BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2();
>> 1368:   code_req += bs->estimate_stub_size();
> 
> I would be careful with this. I tried this change as part of [JDK-8331253](https://git.openjdk.org/jdk/commit/3383ad6397d5a2d8fb232ffd3e29a54e0b37b686) fix. But then I have to rollback that to avoid regression [JDK-8333226](https://github.com/openjdk/jdk/pull/19531)
> 
> It is affecting inlining decision (InlineSmallCode) and have to be handled carefully.

Here is PR for original change: https://github.com/openjdk/jdk/pull/19029

-------------

PR Review Comment: https://git.openjdk.org/leyden/pull/28#discussion_r1934426141