DO NOT REPLY [Bug 51625] New: [PATCH] The hashCode() of o.a.f.fo.properties.CommonFont is always 0.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51625 Bug #: 51625 Summary: [PATCH] The hashCode() of o.a.f.fo.properties.CommonFont is always 0. Product: Fop Version: all Platform: PC OS/Version: Mac OS X 10.4 Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: alex.gio...@gmail.com Classification: Unclassified The hashCode of o.a.f.fo.properties.CommonFont is always 0 due to an initialization error of the cached hash value. This causes a lot of extra work on the org.apache.fop.fo.properties.PropertyCache and some more memory usage. The patch except correctly initializing the hash value, it also fixes the rest of the hashCode() implementation. It used the fontStretch twice instead of using the fontWeight hashCode. Also it replaces the equals() method with the one that is auto generated by Eclipse because the values were checked using object identity instead of the equals method. Please apply this patch soon. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51625] [PATCH] The hashCode() of o.a.f.fo.properties.CommonFont is always 0.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51625 --- Comment #1 from Alexis Giotis 2011-08-05 14:16:02 UTC --- Created attachment 27354 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27354 The CommonFont.java patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51625] [PATCH] The hashCode() of o.a.f.fo.properties.CommonFont is always 0.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51625 Alexis Giotis changed: What|Removed |Added Attachment #27354|0 |1 is obsolete|| --- Comment #2 from Alexis Giotis 2011-08-05 16:51:24 UTC --- Created attachment 27356 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27356 Updated patch (fixes init value from 1 to -1) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51625] [PATCH] The hashCode() of o.a.f.fo.properties.CommonFont is always 0.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51625 Alexis Giotis changed: What|Removed |Added OS/Version|Mac OS X 10.4 |Mac OS X 10.6 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class
https://issues.apache.org/bugzilla/show_bug.cgi?id=46962 --- Comment #6 from Alexis Giotis 2011-08-05 20:21:52 UTC --- Created attachment 27357 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27357 Concurrent map based implementation of property cache supporting hashCode collisions -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46962] Deadlock in PropertyCache class
https://issues.apache.org/bugzilla/show_bug.cgi?id=46962 Alexis Giotis changed: What|Removed |Added Attachment #27342|0 |1 is obsolete|| Attachment #27343|0 |1 is obsolete|| Attachment #27357|0 |1 is obsolete|| --- Comment #7 from Alexis Giotis 2011-08-05 20:31:09 UTC --- Created attachment 27358 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27358 Patch with rewritten PropertyCache (trunk revision 1154337) In short, the new PropertyCache implementation attached is: - Up to 3 times faster (depending on the tests, the -Xmx, and the retention or not of strong refs to he cached entries) - 3 times less lines of code - Obviously thread-safe - Written using JDK5 generics - Has similar memory requirements Additionally this patch fixes broken hashCode() and equals() methods of classes extending Property (including the patch in bug 51625). Those caused in tests many hashCode collisions. In more detail, I wrote 2 new implementations of PropertyCache (one in this patch and the one in attachment 27357) and tested both against the original one with the fix contained in attachment 27343. When strong references to the cached entries are kept, then the performance of all is similar. When they are not (more common case), the ones based on the concurrent hash map are up to 3 times faster. The tests were allocating 1M (million) Property instances from which 100K were equal (but different instances). The first implementation based on the concurrent map supports caching not-equal objects with the same hashcode but is fairly complex. The one attached in the final patch does not. After some experimentation and tests with large (1000 page) documents hashcode collisions were caused due to buggy hashCode and equal implementations. Handling this case has a performance penalty. In a test that caches 1M entries from which there are only 100 different hashCodes the time to complete was: 52 seconds for the initial implementation 12 seconds the the concurrent map that can cache not-equal objects with the same hashcode. 1 second for the concurrent map that keeps the more recent one. In other words, in this case (which is due to buggy hashcode()/equals), the cost of creating a new instance and replacing the previously cached one is by far smaller that the one to maintain in memory the different instances. Note that this implementation does not provide any guarantee related to the uniqueness of equal instances when concurrently executed. Such a guarantee is not only complex to code but also it requires additional locking. In practice, it is not very probable that this will happen, finally there will be only one and of course this should be a tolerable situation. After all, the caching can be globally disabled with the same system property as before. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.