[
https://issues.apache.org/jira/browse/WICKET-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Heigl resolved WICKET-6977.
----------------------------------
Fix Version/s: 10.0.0
9.10.0
Resolution: Fixed
> 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
> Assignee: Thomas Heigl
> Priority: Minor
> Fix For: 10.0.0, 9.10.0
>
>
> 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)
