[jboss-jira] [JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe

[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1049: ------------------------------------------ I've been looking into the cost of just doing synchronization/locking instead of what's in https://github.com/wildfly/wildfly-core/pull/1207. I been testing boot time on my quad core macbook, looking at various approaches to solving this. I tested standalone boot time with the standalone.xml and standalone-full.xml configs. I would shut down all CPU-draining apps, build the server, then start/stop the config 4 times to warm any FS caches, and then start/stop the server 7 times recording the logged start up time. I'd throw out the lowest and highest value and calc an average of the other 5. Results, in ms, standalone.xml and then standalone-full.xml: master[1] 2479 3395 no-lock[2] 2547 3276 sync[3] 2561 3363 lock[4] 2568 3358 lock2[5] 2546 3340 [1] The "master" figures are current WildFly master. [2] https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... (PR #1207) [3] Locking using "synchronized" -- https://github.com/wildfly/wildfly-core/compare/master...bstansberry:sync... [4] Locking using java.util.concurrent.lock https://github.com/wildfly/wildfly-core/compare/master...bstansberry:lock... [5] Same as 4 but a slight change in locking in one method. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:lock... -- submitted as https://github.com/wildfly/wildfly-core/pull/1231 Since [5] is competitive with [2] with the default profile, and is competitive with master with the full profile, I'll go with [5]. It is conceptually simpler than [2]. Interestingly enough, through quite a few various boot time tests (not just those reported above) I'd see the approaches using locking performing better than master for the "full" profile, while performing worse for the default profile. The latter is not surprising; the former is. My *guess* is this is because master uses FastCopyHashMap, copying the map for every attribute/operation/child addition. The locking approaches don't need this copying, since the maps are guarded. My guess is full includes more subsystems with more attributes, so more copying cost. I don't delude myself that these figures are highly precise. :) But I've done enough tests to sense that they are reasonable; there is some cost to this fix but not a huge one, and maybe little or none with the full profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)