myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
Date Thu, 20 Dec 2012 15:12:01 GMT
Hi Martin

2012/12/20 Martin Marinschek <>:
> Hi Leo.
> what are you trying to gain from this?
> Here the criticism from the link you provided:
> Criticism
> Some publications do not recommend using object pooling with certain
> languages, such as Java, especially for objects that only use memory and
> hold no external resources.[2] Opponents usually say that object allocation
> is relatively fast in modern languages with garbage collectors; while the
> operator new needs only ten instructions, the classic new - delete pair
> found in pooling designs requires hundreds of them as it does more complex
> work. Also, most garbage collectors scan "live" object references, and not
> the memory that these objects use for their content. This means that any
> number of "dead" objects without references can be discarded with little
> cost. In contrast, keeping a large number of "live" but unused objects
> increases the duration of garbage collection.[1] In some cases, programs
> that use garbage collection instead of directly managing memory may run
> faster.
> what do you say about this?

To avoid the effect over garbage collection, the view pool proposed uses
soft or weak references to hold UIViewRoot instances and to avoid lower
performance by concurrency effect, the pool does not have any
synchronized block it uses a ConcurrentLinkedQueue with a upper
limit set by an atomic var (just one synch block and the performance
will be lower than do not using anything at all).

The effect of use soft/weak references is that the region of memory holding
the instance can be always reclaimed by the garbage collector, avoiding
memory fragmentation.

>From memory perspective, the cache improves memory usage because
less object needs to be created per request, so the pressure over gc
becomes many times lower, and at the end we have less calls for gc
and a better performance at the cost of have a higher memory footprint.

In MyFaces case, we have done the best effort to keep component tree
"as light as possible", which means create the less amount of objects
per component. This makes view creation very fast, but anyway, the
amount of objects that still needs to be created per view are enough to
consider object pooling technique.

The tests done under high concurrency (200 threads) shows an
improvement of about 8% rendering full pages. The reason is the build
view time for our facelets algorithm is already very fast, and render
the view is the operation that takes more time. But in ajax cases
the improvement is even more, because in that case, usually the portion
that needs to be rendered from the view is small, and the build view
time becomes more significant. The difference will be more significant
if the view is larger.

Is the technique good enough to be included in MyFaces? In my
opinion yes, because given the considerations done there is a gain even
in the most simple cases. But not everything is perfect. The technique
suppose PostAddToViewEvent will not be called in each request, if you
use c:set, ui:param or something that makes ValueExpressions depends
on VariableResolver and in that way make necessary to create them
at each request, the view becomes non poolable, and it also requires
some small modifications over components to allow reset the component.

In any case, the proposed patch will help to clear the misunderstandings
about stateful vs stateless web frameworks and the implications in

best regards,


> best regards,
> Martin
> On Mon, Dec 17, 2012 at 5:23 PM, Leonardo Uribe <> wrote:
>> recover
> --
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> Professional Support for Apache MyFaces

View raw message