[
https://issues.apache.org/jira/browse/FELIX-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517245#comment-15517245
]
Rob Ryan commented on FELIX-5363:
---------------------------------
yes it is about getFrameworkFromContext. true.
There is only one framework in this case.
It doesn't appear to be a matter of expensive work, per se, rather expensive
synchronization. No time under getFrameworkFromContext is attributed to any
called methods, and it starts with a synchronized block. It appears likely
that this call simply gets called enough that there are collisions enough to
have java expand this particular synchronized block into a full (expensive)
lock vs its usual cheaper treatment of synchronized blocks with low to no
concurrency.
Note: the raw yourkit data lists plently of java.* things so it isn't likely
that any significant time is being misattributed to getFrameworkFromContext as
opposed to a callee.
> new URL(string) suffers under concurrency
> -----------------------------------------
>
> Key: FELIX-5363
> URL: https://issues.apache.org/jira/browse/FELIX-5363
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-5.4.0
> Reporter: Rob Ryan
> Assignee: Karl Pauls
> Attachments: Merged-callees.csv
>
>
> Under moderate concurrency (25threads) and frequent use of new
> java.net.URL(string) a bottleneck was seen with yourkit. In one test
> involving HTML page generation new URL(url) was seen to take 20% of time (via
> yourkit).
> This was tracked to
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext()
> URLHandlers.java which accounted for 99% of the time used by new URL(url).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
