I am sorry if this has been answered already, but do you have any info
that shows performance comparison single vs milti threaded build? If you
happen to have any profiler snapshots that show where time is spent
during single and multi threaded builds, I am interested to see these too.
PS: we got first // build question on tycho-users list last week ;-)
--
Regards,
Igor
Kristian Rosenvold wrote:
Now that the first Jira issue has arrived on parallel maven, I think
it's time I do a little summary of how things are ATM. For those of you
that don't routinely hang around at #maven-dev on irc:
I have found and fixed a series of insidious concurrency problems in
several plexus components (thanks a million Benjamin for all help with
discussing & patching those!)
The issues were:
http://jira.codehaus.org/browse/MNG-4632
http://jira.codehaus.org/browse/PLXUTILS-130
http://jira.codehaus.org/browse/PLXCOMP-149
The last two of these issues affect linear-maven-2.2.1 too and can be
the cause of deadlocks (in numerous plugins) and data
corruption/deadlock/other interesting behaviour in the jar/war/ear/?ar
plugins.
plexus-utils (2.0.5), plexus-io (1.0) and plexus-archiver (1.0) are the
required dependencies to stay clear. I will file issues on the affected
plugins/modules RSN.
Both parallel mode and weave mode now work stunningly well, and all my
test builds are green (or otherwise accounted for). I have one last
minor update on weave that's running the tests now, and I'm targetting
http://jira.codehaus.org/browse/MNG-4633 for beta-2.
All of Arnaud's projects that I was able to build with regular m3 on
java 6 also build with parallel m3 now.
The CI running the tests can be seen here; and it's quite interesting.
I'll leave it to the reader to spot the 6-core i7 980X vs the C2D 2.5
Ghz in those graphs ;)
Weave mode: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1W
PArallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-CH1
m3 weave: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31W
m3 parallel: http://rosenvold.dyndns.org:8085/browse/PARALLEL-M31
This CI has now run 40.000 parallel builds (most of which are
non-public) and all errors are accounted for. Those of you surfing
around a little more will see a couple of disabled builds, which also
has known causes.
Plugins
=========
I have only managed to find "real" concurrency problems in the EAR
plugin and modello as of yet. Modello is fixed in trunk, ear is
not started AFIK.
All the other stuff I've seen in the core plugins relate to the
plexus-issues.
Our jira issue is from a user who's complaining about plugins not
working, and I think he's somewhat right in that we have to make some
kind of system to indicate compatibility with the -T option.
Although several strategies may be recommended, my personal favourite
is to make a @threadsafe javadoc annotation and make M3 core
COMPLAIN LOUDLY about plugins that are unmarked, then proceed as
requested (i.e. complain but still run threaded).
The problem with these things is that thread safety is not necessarily a
constant, and in the next 9 months there will be issues. So for some
plugins @threadsafe might equally much express an intent as much as it
reflects reality. So that makes me a bit sceptical to @threadsafe too.
Aggressively displaying the link to the wiki page containing the
most up-todate threading info may be an equally good solution; maybe
even adding a WARNING: Experimental or something to the build output.
http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in
+Maven+3 (if it's up), should contain all the information needed on
which plugins are known to have issues. But as we all know, it's an open
ecosystem.
Documentation
============
I will keep the wiki page updated, provided cwiki.a.o actually stays
up ;)
I will add a section on mojo threading models/threading concerns to the
mojo api specification.
I think we have to take some extra measures to keep users out of the
issue trackers on this one, or at least make sure they go to the right
place.
What do you think ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
