Looking ahead: proposed Hg forest consolidation for JDK 10

[Maurizio Cimadamore]

On 19/10/16 01:22, Jonathan Gibbons wrote:
>
>
> On 10/18/2016 06:59 AM, Erik Helin wrote:
>>>
>>
>> You mean that you can work on the langtools repository only? Do you 
>> only need a boot JDK? How do you build in those cases? I assumed that 
>> langtools, like all the other repositories, were building from the 
>> top repository? 
>
> Currently, with the langtools repo, you only need the repo and a 
> reasonably-recent build of JDK.  The langtools repo has its own Ant 
> script to build the langtools modules, which is easy enough since it's 
> all Java code. The Ant script is set up to support IDE integration and 
> debugging: some of us use NetBeans, others use IntelliJ. The 
> --patch-path option is used to override the langtools modules in the 
> JDK image with the new locally built versions.
>
> The technique should be reasonably applicable to anyone just working 
> on plain old Java code.
Pretty much what Jon said - you can work in langtools in isolation, 
provided you have a pointer to a reasonably recent JDK 9 image (the 
degree of freshness of such JDK image depends on how much work is going 
on - if things are stable, 'recent' could well mean 3-4 months old; if 
things are hot - as now - 'recent' typically means a couple of weeks).

Yesterday I did some experiments to compare build times of the local 
langtools script vs. toplevel make; the table below summarizes the 
results. I've compared both 'cold  build' times (i.e. build from a clean 
state) and 'incremental build' times. I did the latter by touching a 
file in a given module, and then relaunching the build command again.


*Test type*
	*Time (make)*
	*Time (ant)*
all 5 langtools modules (cold build)
	4m
	18s
java.compiler (incremental)
	28s
	3s
jdk.compiler (incremental)
	25s
	3s
jdk.javadoc (incremental)
	12s
	2s
jdk.jdeps (incremental)
	7s
	2s
jdk.jshell (incremental)
	5s
	2s



As you can see, the different in the cold case is pretty stark. Now, you 
should normally not pay the price for this always - however, any change 
that triggers a 'reconfigure' can potentially spawn a cold build time.

If we move on to consider incremental build times, we can see two 
categories:

* java.compiler, jdk.compiler, jdk.javadoc - those tools have an 
'interim' stage in the toplevel make build - which make incremental 
compilation quite slower compared to ant
* jdk.jdeps and jdk.jshell are simple leaves - while the ant build is 
faster, I think the difference is not significant

I tend to work on jdk.compiler most of the time, and, for me, the 
difference in usability between a 30s incremental build and a 3s one is 
pretty significant, especially when working with an IDE. Which is why, 
at the moment at least, I'm sticking with the internal ant build.

Of course, should things improve for the modules in the first category, 
then the extra benefits of using a single build would be enough to 
offset the minor incremental slow down (and the one off 'cold' big slow 
down).

P.S.
I've seen other ant builds around (Nashorn IIRC) - I'd be interested to 
know what other folks in similar situation think about this.

Maurizio