You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Alan Stange (Jira)" <ji...@apache.org> on 2022/04/25 03:17:00 UTC

[jira] [Created] (WICKET-6977) hashCode computations generate excessive garbage objects

Alan Stange created WICKET-6977:
-----------------------------------

             Summary: hashCode computations generate excessive garbage objects
                 Key: WICKET-6977
                 URL: https://issues.apache.org/jira/browse/WICKET-6977
             Project: Wicket
          Issue Type: Improvement
          Components: wicket-core
    Affects Versions: 9.9.0
         Environment: Linux, JDK18
            Reporter: Alan Stange


We observed excessive GC pressure on Wicket servers with complex component hierarchies.   Using profilers and some code inspection, we noticed an anti-pattern being used in the hashCode computations for some classes.    The slow code was first observed in AbstractJavaScriptReferenceHeaderItem, and then in related CSS classes as well.

The common pattern in use was similar to
{noformat}
int hashcode = Objects.hash(ob1, obj2, ... objn){noformat}
which works by creating a Object[] array of size n, copying the object references into it and then calling the varargs hash() method.   In some cases, an intermediate computation was also being autoboxed, using still more memory.

This code can be replaced with calls like

 
{noformat}
int result = obj1.hashCode();
result = 31 * result + obj2.hashCode()
result = 31 * result + obj3.hashCode;
return result;

{noformat}
which is several times faster and does not generate any garbage objects.

The impact is large when a containing map is resized for larger component hierarchies, resulting in repeated hashcode re-computations.

A pull request was submitted with proposed changes to the code for this issue: [link #513|https://github.com/apache/wicket/pull/513]

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)