Parallelizing code is great when your single machine is
never under very heavy load (all worker threads used).
Under very heavy load, the parallelization management code
simply adds additional overhead (my experience).
To shed, throttle, rollback, checkpoint&freeze or migrate
(transactional?) tasks as heavy load
conditions are approached on a machine is a system-level,
multi-machine, architectural issue that is not easily
inserted into an existing code base.
Richard
On 07/05/2011 08:52 AM, Andrea Del Bene wrote:
My fault Martin, I have not explained well myself. I try to summarize
what I wanted to say:
-Java 7 introduces some tools to implement Fork/Join parallelism (
http://en.wikipedia.org/wiki/Fork-join_queue )
-Should we adopt this pattern? Is Wicket ready for implementing such a
pattern?
Render phase is probably the most time-expensive part of Wicket. Do you
think it could be splitted in subtasks?
For example it would be nice if a page could apply Fork/Join parallelism
to render its children components.
I'm saying only that JDK7 based solutions should be in a separate
module and pluggable.
If my application runs on JDK7 then I can replace the default
functionalityX (based on JDK5/6) with the improved one (based on
JDK7).
On Tue, Jul 5, 2011 at 2:52 PM, Andrea Del Bene<adelb...@ciseonweb.it>
wrote:
Well, I wasn't expecting a rapid or easy adoption of JDK7, but I
think that
is useful starting to explore how to parallelize some of the stages of
Wicket's rendering pipeline. This could lead to a strong performance
gain in
the future, with adoption of JDK7 or using a parallel programming
library.
You know that Wicket still uses JDK 1.5 (not even 1.6) because many
users still use JDK1.5 and cannot upgrade to the newer.
So any improvements based on JDK7 should be out of wicket-core. They
can be plugged but the default impl should be 1.5 based.
For example you can create ModificationWatcher based on NIO2 but it
will in wicket-jdk7 module (or similar) or in wicketstuff project.
For Wicket 1.6 we can move to JDK6 but this will be discussed later.
Usage of JDK7 for frameworks is not very close.
On Tue, Jul 5, 2011 at 2:11 PM, Bruno Borges<bruno.bor...@gmail.com>
wrote:
Some internals of Wicket don't use collections. Take for instance
ResourceNameIterator.
But certainly there are some things that can be used, like the new
File
watching API.
*Bruno Borges*
www.brunoborges.com.br
+55 21 76727099
On Tue, Jul 5, 2011 at 9:04 AM, Andrea Del
Bene<adelb...@ciseonweb.it>wrote:
I know it could sound a bit premature, but hasanyone starting to
think
how
improve Wicket with the new JDK? I think that the new concurrency and
collections API could help to speed up Wicket.
Has anyone run some tests?
--
Quis custodiet ipsos custodes
