[
https://issues.apache.org/jira/browse/FELIX-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160285#comment-14160285
]
Thomas Watson commented on FELIX-4656:
--------------------------------------
Can you explain more about the Path data-structure. I do not follow what the
Path holds and how it determines that it has already been attempted. A
solution contains many paths to different capabilities. Because a path is bad
in one combination does not mean it will be bad if a different combination is
used with other paths.
I did run the code through my own tests and it does pass except for one test
that is testing substituted exports. I need to investigate, but I suspect it
is an ordering issue with the test and not an issue with the resolver.
While using the felix resolver I had to move to doing an incremental resolution
(one bundle at a time) to avoid explosions in the algorithm. I reverted this
back to doing "big bang" resolution. I did find that the improvements here had
about a 3x improvement on resolution. At this point I am unsure if that 3x
improvement was a result of the improvements on memory consumption and making
the candidates copy more efficient or if it was the 'path' optimization.
> Improve memory usage of the resolver
> ------------------------------------
>
> Key: FELIX-4656
> URL: https://issues.apache.org/jira/browse/FELIX-4656
> Project: Felix
> Issue Type: Improvement
> Components: Resolver
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Fix For: resolver-1.2.0
>
>
> During big resolutions (> 100 bundles), the memory consumption can become
> very huge, mostly by keeping a lot of copies of the Candidates object.
> I want to lower the memory requirements of the resolver without touching the
> algorithm at all (which would be a different improvement).
> This can be done by using :
> * lower memory intensive collections
> * do smart copies of those collections (where they would only actually copy
> the data when modify)
> The second item is slightly more difficult to achieve, as the maps in the
> Candidate objects contains Set and List, which would mean that those must be
> copied too. So it could actually be complementary, if achievable.
> For the first one, the HashMap and HashSet are very memory intensive. I'll
> introduce two new collections which will lower the requirements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
