JDK-4229449 : RFE: Please multithread javac for better performance
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.2.0,1.2.2
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 1999-04-14
  • Updated: 2000-10-31
  • Resolved: 2000-10-31
Related Reports
Relates :  
Description

Name: krT82822			Date: 04/14/99


Please multithread javac to give better performance when compiling multiple
classes at once on multiprocessor machines, eg the stub classes
output by the idl compiler.
(Review ID: 56948) 
======================================================================

Name: skT88420			Date: 12/07/99


java version "1.2.2"
HotSpot VM (1.0.1, mixed mode, build f)


(See also bug id 4229449: please multi-thread javac).

Since interfacing make with javac is difficult for various reasons, and given
that javac already has to compute much of the dependency information that make
would need, may I suggest the following:

A new option to javac, say -XbuildOnlyOutOfDate, which, when javac is given one
or more .java source files, rebuilds *only* those that it determines to be out
of date.

Thus a typical makefile could look soemthing like this:

SRCS=A.java B.java C.java

out.jar: $(SRCS)
    javac -XbuildOnlyOutOfDate $(SRCS)
    jar cvf $@ $(SRCS:%.java=%.class)

IE, make delegates all the dependency analysis and selective rebuild to javac
for the Java sources.

If javac were also multithreaded to take advantage of multiple processors and/or
to overcome I/O latency, this could beat make or a normal javac solution hands
down.  A great leap forward for productivity.
(Review ID: 98733)
======================================================================

Comments
EVALUATION I think that multithreading 'javac' could yield significant performance increases in some cases. Note that the proposed -XBuildOnlyOutOfDate switch would indicate to the compiler which files comprised the project to be compiled, which must be stated up front- -- if they were to be discovered incrementally as dependency predecessors of a "main" compilation unit, parallelism would be lost. See 4304048 for other thoughts on the command-line semantics of the compiler. william.maddox@Eng 2000-01-28 ---------- Perhaps I should be flattered. The user is asking me to implement my PhD thesis "Parallel Incremental Compilation". Yes, the compiler should be faster. How we do that is none of the user's business. For example, sometimes we need to build things whose sources are not out of date because it depends on something else that is out of date. In short, the proposed command-line option doesn't make sense. Moreover, it isn't safe for us to depend on timestamps to determine when we last compiled something. I'm rejecting the specific commandline suggestion and the specific suggestion for how to improve performance. I'm well aware of techniques that we can use toward performance improvements, including multithreading. But this RFE is a bit too specific in suggesting how we do that.
11-06-2004

WORK AROUND Name: krT82822 Date: 04/14/99 In some circumstances, and with the right tools (eg gmake) it is possible to do multiple builds in parallel as separate processes, but javac could do a better job. ====================================================================== Name: skT88420 Date: 12/07/99 Ugly sed/awk/gmake combos. (Review ID: 98733) ======================================================================
11-06-2004