[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765491#action_12765491
]
Karl Pauls commented on FELIX-1746:
-----------------------------------
Well, I don't think it does two copies on every read. It only does one as the
values() method result is just a wrapper around the map. I agree that it needs
to get the same lock twice but as it is doing that in two calls directly after
each other the JIT should lift that into just one.
As almost always when taking about concurrency, its not that easy to reason
about the best solution. In this case, the copy-on-write will shift the burden
to the registration of services which might equally impact performance on
startup...
Regarding your statement that Felix goes a bit crazy with synchronization, it
is true that we spend a lot of time to get synchronization and locking correct.
I think we are finally close to a framework that does lock correctly (a lot
more correctly than some other frameworks I know of - thats for sure) which is
why I need more time to look into your patch and try to test it with real live
examples to see what its impacts really are. For example, while it is true that
the edge-case change in alt2 is orthogonal and would need to be made to both
patches, it just goes to show that it really hard to ensure we don't introduce
bugs for other scenarios when we make changes like this.
I'm not against introducing a COW map and going with your patch but I need more
time to investigate the impact it might have.
Question is, should I go ahead and apply my patch (as I wouldn't have a big
problem with making it part of the next 2.0.2 release) and we keep this issue
to investigate a more concurrent COW map based implementation for a future
2.2.0 release (probably that would include looking into other places where we
could benefit from a COW map inside the framework)? Alternatively, we can just
do nothing for now and I will try to find the time to look into your patch some
more first?
> Eliminate contention on ServiceRegistry.getServiceReferences(String, Filter)
> ----------------------------------------------------------------------------
>
> Key: FELIX-1746
> URL: https://issues.apache.org/jira/browse/FELIX-1746
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: felix-2.0.0
> Reporter: Jed Wesley-Smith
> Assignee: Karl Pauls
> Attachments: blocked-threads.gif.jpg, FELIX-1746-alt.patch,
> FELIX-1746-alt2.patch, FELIX-1746.patch
>
>
> Performance testing has shown that there is significant contention on the
> ServiceRegistry object's monitor during startup. This is caused by Spring DM
> making lots of calls to the synchronized method
> ServiceRegistry.getServiceReferences(String, Filter). This method is
> synchronized in order to protect the m_serviceRegsMap HashMap, but the method
> does a lot more work than simply accessing the map.
> Propose changing the ServiceRegistry to use a thread-safe Map implementation
> that does not require external synchronization, in particular a
> CopyOnWriteMap. I will add a patch that includes a CopyOnWriteMap
> implementation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
