The best times I have gotten have been with the VMs in Stockholm, VMware base,
4 vcpus, lots of RAM.
I don't have any newer raw hardware, just VMs.
However, as I stated, it's erratic. We have some issues somewhere.
I think Erik has gotten even faster times with his beefy desktop, not sure what
t
The build times for incremental builds look awesome. Now I'm really
looking forward to the new build system! Thanks!
Regarding partial builds: as long as the other components don't add
dependencies that we didn't use to have before (when working on the jdk
repo only), I guess it's all right, t
On 12/09/2012 19:49, Kelly O'Hair wrote:
Some stats on incremental builds. Not partial builds..
This is an older Solaris machine svc6.us.oracle.com, building the complete
openjdk forest from scratch
for 64bit including images took less than 14 minutes (parallel build setting
was 8) and images
Windows X64 in VM can build within 25mins? That's quite impressive. Can
you share what VM/OS/CPU/mem you are using? I only have VirtualBox
running on Linux X64 now, but will consider moving to some other
platforms if it helps a lot.
Thanks
Max
On 09/13/2012 04:32 AM, Kelly O'Hair wrote:
Wind
Oookay, long story, this was when we used jdk6 to build jdk7, same kind of
problem could occur when using jdk7 to build jdk8:
jdk7javac used new features and classes in jdk7, for example:
java/util/Objects.java java/util/ConcurrentModificationException.java
java/io/File.java java/nio/file/*
Windows X64 CYGWIN Openjdk builds run between 16 and 25mins, depending on the
machine used (hardware vs. VM),
how many CPUs etc. But it's a bit erratic, depends on lots of things. We are
still working around some CYGWIN issues.
The incremental builds should be similar. I don't have any numbers ri
What about windows?
-igor
On 9/12/12 11:49 AM, Kelly O'Hair wrote:
Some stats on incremental builds. Not partial builds..
This is an older Solaris machine svc6.us.oracle.com, building the complete
openjdk forest from scratch
for 64bit including images took less than 14 minutes (parallel build
On Sep 12, 2012, at 8:54 AM, Jonathan Gibbons wrote:
> On 09/11/2012 10:46 PM, Fredrik Öhrström wrote:
>> However, this begets the question why -Xprefer:source was added in the first
>> place. If I remember correctly,
>> this was over a year ago. It turns out that the default behavior for
>> im
Some stats on incremental builds. Not partial builds..
This is an older Solaris machine svc6.us.oracle.com, building the complete
openjdk forest from scratch
for 64bit including images took less than 14 minutes (parallel build setting
was 8) and images took 2mins of this 14mins:
-- Build times
On Sep 11, 2012, at 10:46 PM, Fredrik Öhrström wrote:
> 11 sep 2012 kl. 21:59 skrev Alan Bateman:
>> With a sjavac config I touched one source file and the incremental build
>> took 36s so much better. In this case the one class caused 77 classes to be
>> re-compiled, 10 native files, and 2 sha
On 09/11/2012 10:46 PM, Fredrik Öhrström wrote:
However, this begets the question why -Xprefer:source was added in the first
place. If I remember correctly,
this was over a year ago. It turns out that the default behavior for implicit
compilation (which is necessary for sjavac:s multi core supp
On 9/12/2012 1:54 PM, Alan Bateman wrote:
On 12/09/2012 06:46, Fredrik Öhrström wrote:
:
Excellent. I hope you realize how valuable it is that the build system
recompiled the proper source files, then proceed to generate the the
jni headers output
because of native methods in those classes tha
On 12/09/2012 06:46, Fredrik Öhrström wrote:
:
Excellent. I hope you realize how valuable it is that the build system
recompiled the proper source files, then proceed to generate the the jni
headers output
because of native methods in those classes that were recompiled, then proceed
to recompi
11 sep 2012 kl. 21:59 skrev Alan Bateman:
> With a sjavac config I touched one source file and the incremental build took
> 36s so much better. In this case the one class caused 77 classes to be
> re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the
> other hand, the old
On 11/09/2012 19:23, Fredrik Öhrström wrote:
Den tisdagen den 11:e september 2012 skrev Alan Bateman:
So far my experience is that touching native code and re-building
is super fast, it's on par to executing specific make files in the
old build (while wearing the appropriate amulet
Den tisdagen den 11:e september 2012 skrev Alan Bateman:
>
> So far my experience is that touching native code and re-building is super
> fast, it's on par to executing specific make files in the old build (while
> wearing the appropriate amulet around one's neck of course). Touching java
> classes
On 10/09/2012 15:00, Magnus Ihse Bursie wrote:
In the new build system, fast incremental builds of Java code is
dependent on the new "smart javac", which unfortunately has still not
proven stable enough to be enabled by default, even in the
experimental build-infra forest. It is still our hop
On 10/09/2012 15:20, Magnus Ihse Bursie wrote:
:
In build-infra, there is currently a "somewhat partial build" feature
that is implemented like this:
1) You check out a "master forest", containing all repos. You only
need to do this checkout once, and you are not required to pull/update
it (
On 11/09/12 14:37, Anthony Petrov wrote:
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
And this re-builds both AWT classes and
+1
--
best regards,
Anthony
On 9/10/2012 6:52 PM, Weijun Wang wrote:
Sorry I was not clear, by "clone the repo(s)", I mean either only the
jdk repo, or plus the jdk/*/closed ones. I almost never clone other
repos (langtools, hotspot, ...).
-Max
On 09/10/2012 10:48 PM, Weijun Wang wrote:
It
Is this a somewhat correct understanding? Am I missing something? Are
there some other reason apart from speeding up the build to do partial
builds? How many users out there are actually using partial builds?
I believe, as you've seen in the replies, the question is better
rephrased as "How m
Can not agree more.
For repos further in the food chain (such as deploy, etc) this is even
worse.
Often we do not really need to build jdk repo.
We doing (quick) partial builds in Hudson to run tests continuously.
We also often need to build on "test" systems where JDK build env is not
set.
Ge
A huge step backwards.
I don't want to have to clone or keep hotspot up to date
and I prefer using the 'RE' builds of hotspot to any I would create.
I have never found this fragile. Its worked well for over 10 years ...
-phil.
On 9/10/2012 8:36 AM, Jonathan Gibbons wrote:
Having to compile hotsp
I focus on pack200, java launcher and javac, and for the launcher
I am sometimes forced to use windows as the development platform.
Building incrementally the launcher, saves me a lot of time.
This is how it works:
1. make launcher specific files and test with ALT_OUTPUTDIR.
2. build all the to
Having to compile hotspot every time one creates a new repo seems like a
very significant step backwards. I can clone and build langtools in 45
seconds.
$ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd
langtools ; lt.ant build-all-classes )
destination directory: langtools
Magnus,
I'm guessing that most developers use partial builds.
In the langtools/ world, we only build the langtools component, and even
then, sometimes only javac. We can then use the result to run our
tests. We do not want to -- and would strongly resist having to --
rebuild all of JDK every
Sorry I was not clear, by "clone the repo(s)", I mean either only the
jdk repo, or plus the jdk/*/closed ones. I almost never clone other
repos (langtools, hotspot, ...).
-Max
On 09/10/2012 10:48 PM, Weijun Wang wrote:
It's not uncommon that I just clone the repo(s), do a quick build, run
sev
It's not uncommon that I just clone the repo(s), do a quick build, run
several tests and abandon it, for example, if I want to try my code
changes on a different platform (from my daily work machine). Therefore
I find the jdk-only build very useful.
-Max
On 09/10/2012 10:20 PM, Magnus Ihse Bu
On 2012-09-10 14:13, Alan Bateman wrote:
I think this is a great topic to discuss.
At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say "partial build" then I
mean they build a subset of repositories, not all of them. So folks
wo
On 2012-09-10 14:13, Alan Bateman wrote:
When you say "sub-directory builds" then I think you mean incremental
builds, or "poor-man increment builds" as I call it. I think the
majority of people working in the jdk repository, at least in Oracle,
do this because they know the area and know which
I think this is a great topic to discuss.
At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say "partial build" then I
mean they build a subset of repositories, not all of them. So folks
working in the jdk repository tend to just b
On 10/09/2012 12:26, Magnus Ihse Bursie wrote:
I'd like to start a discussion about the partial builds; what problem
they solve and the best way to solve these problems in the new
build-infra world.
I'm currently investigating on how to handle the equivalence to partial
builds in the new build s
I'd like to start a discussion about the partial builds; what problem
they solve and the best way to solve these problems in the new
build-infra world.
I'm currently investigating on how to handle the equivalence to partial
builds in the new build system. My goal is to see to it that the new
34 matches
Mail list logo
