Bug 1038689

Summary: Do not allocate collection for Configuration.rawConfigurations by default
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: Configuration, PerformanceAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.9CC: hrupp
Target Milestone: ---   
Target Release: RHQ 4.10   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-23 12:31:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1069642    
Attachments:
Description Flags
Possible patch none

Description Heiko W. Rupp 2013-12-05 15:57:10 UTC
Created attachment 833226 [details]
Possible patch

Configuration.rawConfigurations is allocating a HashSet by default, but as raw configurations are (almost) not used, this memory is allocated for nothing.
An empty HashSet consumes around 3kB of the heap, so with 10k resources, that all have a resource configuration object we would allocate 10k HashSets with 3MB heap for nothing.

Comment 1 Heiko W. Rupp 2013-12-05 16:04:09 UTC
It may be that this cost reduced in java7u40 and later
http://java-performance.info/core-java-7-change-log/

I nevertheless think it may be good not to allocate the HashSet in the first place, as not everyone is on 7u40 and not allocating the object itself also saves memory.

Comment 2 Heiko W. Rupp 2013-12-06 10:18:51 UTC
As followup: an empty HashMap/HashSet still allocate 80 bytes and an empty ArrayList still 24 bytes, so with 10k resources and 10k plugin configurations we still save 800k bytes of heap with that change.

Comment 3 Heiko W. Rupp 2013-12-06 14:10:36 UTC
There is something not quite right with the patch. I have seen this fly by (but only once )

Caused by: org.hibernate.HibernateException: A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance: org.rhq.core.domain.configuration.Configuration.rawConfigurations
        at org.hibernate.engine.internal.Collections.processDereferencedCollection(Collections.java:113) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.engine.internal.Collections.processUnreachableCollection(Collections.java:66) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.event.internal.AbstractFlushingEventListener.flushCollections(AbstractFlushingEventListener.java:247) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:100) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1212) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:400) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]
        at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:104) [hibernate-core-4.2.0.CR1.jar:4.2.0.CR1]

Comment 4 Heiko W. Rupp 2014-02-05 09:36:34 UTC
master 52145f9

Comment 5 Heiko W. Rupp 2014-04-23 12:31:34 UTC
Bulk closing of 4.10 issues.

If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.