United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4229449 RFE: Please multithread javac for better performance
JDK-4229449 : RFE: Please multithread javac for better performance

Details
Type:
Enhancement
Submit Date:
1999-04-14
Status:
Closed
Updated Date:
2000-10-31
Project Name:
JDK
Resolved Date:
2000-10-31
Component:
tools
OS:
generic
Sub-Component:
javac
CPU:
generic
Priority:
P5
Resolution:
Won't Fix
Affected Versions:
1.2.0,1.2.2
Fixed Versions:

Related Reports
Relates:

Sub Tasks

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
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)
======================================================================
                                     
2004-06-11
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.
                                     
2004-06-11



Hardware and Software, Engineered to Work Together