RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks

[Vladimir Kozlov]

On 10/17/19 12:32 PM, Schmidt, Lutz wrote:
> Hi Vladimir,
> 
> thanks for looking at the change.
> 
> You should have seen "if (!UseNewCode)". The intention was to leave in the "old" code that I tested against. The "old" code already has improvements over the "original" code. This will definitely be removed before submit.
> 
> The "#if 0" disables code which I regard helpful but which is just too expensive to have it active, even when guarded with !PRODUCT and VerifyCodeHeap.
> 
> If I understand your comments correctly, it is strongly discouraged - if not forbidden - to have #if 0 blocks in the code base. Lesson learned.

RFR assume that the code is tested and is ready to be pushed. It should 
not contain any experimental or dead code. It is difficult to see what 
final code will be if you use UseNewCode.

> 
> Both blocks will be gone in the next webrev I'll post. That'll be tomorrow, if all goes well. I'd like to keep it as RFR. In my opinion, the code is more mature than experimental.

Sounds good.

Thanks,
Vladimir

> 
> Regards,
> Lutz
> 
> 
> On 17.10.19, 20:48, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:
> 
>      Hi Lutz
>      
>      It should be RFC - change seems experimental since it uses #if 0 and
>      UseNewCode2.
>      
>      Nice improvement.
>      
>      Thanks,
>      Vladimir
>      
>      On 10/17/19 12:28 AM, Schmidt, Lutz wrote:
>      > Dear all,
>      >
>      > may I please request reviews for this fix, addressing actually two current performance issues in CodeHeap management. One issue (the stupid one) could be eliminated completely. The other one, in the context of maintaining the code heap segment map, was tamed considerably.
>      >
>      >  From old to new, the following absolute times and speedup factors were observed:
>      >
>      >                    speedup      absolute time [Milliseconds]
>      >                                   old version  new version
>      > ppc  fastdebug      4,700         69,593.484       14.833  (30,000 calls)
>      > ppc  release        4,600         70,069.517       15.215  (30,000 calls)
>      > s390 fastdebug      3,500          7,778.500        2.220  (40,000 calls)
>      > s390 release        6,700          6,935.371        1.026  (40,000 calls)
>      >
>      >
>      > These results are far from clean room measurements. On the other hand, the improvements are so extreme that it can't be just measurement errors. And is it important if the factor is 4k or 3k?
>      >
>      > The performance gain is achieved by taking advantage of properties of the CodeHeap segment map, not by improved coding techniques. You can find more detail in the bug description and as inline documentation in the source code.
>      >
>      > Bug:    https://bugs.openjdk.java.net/browse/JDK-8231460
>      > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/
>      >
>      > Please have a look.
>      > Thank you,
>      > Lutz
>      >
>      
>