Once installed, autoconf ran properly with make reconfigure - thx.
> On May 4, 2016, at 11:24 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > 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 >
