Recently we've seen an article
Why mobile web apps are slow.
This accounts for the most modern implementations that exploit JIT. Author does
favor in the near future.
Here author quotes many references that show that:
In the end author, while saying about some attempts to change the state, has no
final verdict, whether there can be anything done to remedy the problem.
Having roots in C++, we're GC unbelievers. But you know, who will ask your
opinion on that, while there are all those modern languages that try to abstract
xquery, and so on.
There always is a solution to avoid GC completely, like C++ and other (e.g.
Microsoft's C++/CX, or Apple's ARC) do. But, assuming you're entered GC world,
what can be done with it? How do you make it more predictable, less greedy, and
probably more fast?
Our arguments are like this.
How does native code manage object graphs?
Today's solution is reference counting along with weak references to break
cycles in graph.
Can be GC based on this?
developer accurately defines relations in an object graph, one may immediately
achieve the same efficiency as native solution.
If one does not use weak references consistently then object cycles can be
created, so there can appear a graph that is not referenced anywhere in a
program. This graph can be collected with classical GC that scans object roots.
Classical GC part can be used as a debug mode leak detector, and will collect
graph cycles at runtime.
Thus, we claim that a hybrid memory management: reference counting with weak
references plus classical GC is possible; it will be equal to a native memory
management when weak references are properly used, and it will be close to
classical GC without use of weak references.
This solution gives a rule to mitigate GC drawbacks: just use weak references in
appropriate points, and you can continue to live in GC world, where GC is only a
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u