[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5927) Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan

[Eric Dalquist (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45646#comment-45646 ] 

Eric Dalquist commented on HHH-5927:
------------------------------------

So the problem with MapMaker is you're completely giving up the max-size configuration and relying solely on the GC to cleanup, the big danger there is soft-reference only caches can turn into serious performance problems in low-memory high-demand situations as data is constantly removed from the cache, increasing CPU demands. The dual-map approach addresses this fairly well by keeping more frequently accessed data available no matter what the GC state is.

As you noted, the equality check isn't an issue since you're never comparing the values in the cache. I believe in my example you can remove the synchronized keywords as well with the one problem that there could be a cache miss while an entry is being evicted from the strong cache and moved into the weak cache. If we can assume that this case would be rare it wouldn't be a big problem as the plan would be re-generated and placed back into the strong cache, usurping the existing entry. So we would have the very small chance for some extra CPU work with the benefit of being lock-free 

Also in your gist you set concurrency to 1, are you really only expecting 1 thread to update the table at a time?

> Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-5927
>                 URL: https://hibernate.onjira.com/browse/HHH-5927
>             Project: Hibernate ORM
>          Issue Type: Improvement
>          Components: core
>            Reporter: Strong Liu
>            Assignee: Strong Liu
>         Attachments: hotspot.png
>
>
> with Order Demo (real-life simulation attempt test app) I have noticed that there is thread contention on createNamesQuery() which sounds suspicious.
> After investigation it boils down to org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan. It serves as a cache (internal, not replacable) for queries using LRU algorithm (supplied from Apache utils).
> Generally speaking, blocking threads in any sort of caches indicates a problem. From about 2000 calls, 700 got blocked (which is also not nice for context switching).
> I guess, one of the problems is that there is exclusive synchronization in get method:
> public synchronized Object get(Object key) {...}
> which could be replaced by a more granular read-write lock.
> org/hibernate/engine/query/QueryPlanCache.java
> org/hibernate/util/SoftLimitMRUCache.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira