Depends on which OS you are using. You need version 2.69, which is the
latest. On linux, "apt-get/yum install autoconf" should do the trick
unless your distribution is ancient. On windows add autoconf through the
cygwin installer. On mac I think "brew install autoconf" is easiest if
you are into that. If all else fails, downloading the source [1] and
building is pretty easy and straightforward too.
/Erik
[1] http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
On 2016-05-04 16:13, Jim Laskey (Oracle) wrote:
Correct. How do I set up autogen so I can apply these changes?
On May 4, 2016, at 11:11 AM, Erik Joelsson <erik.joels...@oracle.com> wrote:
Build changes look ok to me, but I also helped write most of them.
This certainly adds some build complexity and might seem overly so for just
this optimization. As I understand it, the plan is to expand this build time
profiling concept to generate more profile data that can be used by for example
jlink plugins.
/Erik
On 2016-05-04 15:36, Claes Redestad wrote:
Hi,
please review this change to generate classlists at build-time
bug: https://bugs.openjdk.java.net/browse/JDK-8150044
webrevs:
top: http://cr.openjdk.java.net/~redestad/8150044/top.01/
jdk: http://cr.openjdk.java.net/~redestad/8150044/jdk.01/
hotspot: http://cr.openjdk.java.net/~redestad/8150044/hotspot.01/
The implementation generates an interim image consisting of a minimal
set of modules, then use this to run a small generator program to
load common utilities and facilities and dump the result of this to a
classlist that is then bundled with the final images.
The smaller number of classes on the default classlist (~1100 instead
of ~2500) requires some adjustment to the metaspace defaults.
This achieves the following:
- Removes a manual, error-prone process to update the versioned
classlists
- Ensures the classlists shipped with the JDK/JRE is up to date
with recent JDK changes, e.g., when moving classes from sun.* to
jdk.internal.*
- Automatically picks up and incorporates the output of jlink plugins
such as GenerateJLIClassesPlugin into the classlist
- Supports cross-compilation build targets, although it runs using a
build JDK that can run on the host platform to generate such
classlists (this isn't ideal, but no worse than the current
situation, where the versioned classlist for the host platform is
simply copied to the cross-compiled target)
There are a few concerns/drawbacks:
- It does add complexity to the build, and concern has been voiced that
this would adversely affect build times. However, I'm happy to say
that on my machine build times are roughly the same:
Before:
real 2m37.303s
user 35m33.576s
sys 3m46.476s
After:
real 2m36.168s
user 35m31.232s
sys 3m52.268s
(real time varies ± 5s from build to build)
- Startup on the specific applications we've used to generate the
classlists for previously suffer small regressions. These are
specifically rather dated AWT and Swing-based applications. OTOH,
startup characteristics generally improve on other applications
(minimal VM, jetty, etc...)
Testing: JPRT -testset hotspot
Thanks!
/Claes
