RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111

[Igor Veresov]

Looks good. It’s not related to the change, but could you please consider adding some printing under PrintMethodFlushing && Verbose for the case when the method is made not entrant and include hotness and threshold values?

igor

On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 11/5/13 6:44 AM, Albert Noll wrote:
>> Hi,
>> 
>> could I get reviews for this small patch?
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593
>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/
>> 
>> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There
>> are two issues that cause this regression:
>>   1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a
>> result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache
>> sizes (e.g., <5m).
>>  2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set
>> _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When
>> TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is
>> called much more frequently.
>> 
>> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed.
> 
> Good.
> 
>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking().
>>                    I think that these checks are not needed since 8020151, since we do stack scanning of
>>                    active nmethods irrespective of the value of what need_marking_phase() returns. Since
>>                    the patch removes need_marking_phase() printing out the warning (line 327 in
>>                    sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning
>>                    and the associated code.
> 
> Don't put mark_active_nmethods() under !UseCodeCacheFlushing condition. We always want to reclaim space in codecache.
> 
> To do nmethod marking at each safepoint is fine (we  have to do it to make sure we did not miss live nmethods). But with your changes each safepoint triggers sweep. Do we really need sweep so frequently? Why to sweep if there were no nmethods state change and there is enough space in CodeCache. So I am not sure about removing _request_mark_phase, init it with 'true' is okay.
> 
> The warning was useless so it is okay to remove it and corresponding code.
> 
>> 
>> 
>> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is
>> redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch.
> 
> It is for separate change.
> 
> MethodFlushing is obsolete because we can not run VM without codecache sweeping because we loose performance since we go into Interpreter after codecache filled. Did you tried to run with it OFF? I think it is good candidate to go.
> 
> The problem with UseCodeCacheFlushing is it becomes famous so you can't remove it easily. But don't replace MethodFlushing with it. I think code which currently guarded by MethodFlushing should be executed unconditionally.
> 
> In arguments.cpp there is table for obsolete flags:
> static ObsoleteFlag obsolete_jvm_flags[] = {
> 
> jdk8 is major release so we can change flags. Add MethodFlushing there to remove it in jdk9:
> { "MethodFlushing", JDK_Version::jdk(8),  JDK_Version::jdk(9) },
> 
> Thanks,
> Vladimir
> 
>> 
>> Testing
>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation.
>> 
>> Many thanks for looking at the patch.
>> Best,
>> Albert