RFR: 8175026: Capture build-time parameters to --generate-jli-classes
claes.redestad at oracle.com
Thu Feb 16 13:20:26 UTC 2017
On 02/15/2017 08:09 PM, Mandy Chung wrote:
>> On Feb 15, 2017, at 9:12 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>> currently the file we generate at build time as input to
>> --generate-jli-classes is lost when linking custom images, which means
>> user generate images may perform worse in certain ways, mostly
>> generating more classes during startup.
>> Additionally, there's a strong assumption in --generate-jli-classes that
>> the VM running jlink is going to generate compatible classes with the
>> image being linked, which we can only really guarantee if the java.base
>> in the linked image is of the same version as the java.base in the VM
>> running jlink. This patch tightens these checks to ensure we have
>> freedom to evolve and re-evaluate the implementation in future
>> JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/
>> Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/
> This restriction sounds reasonable and we can enhance this in a future release. I think the plugin can record the configuration in its own format to be independent of the trace output format.
> Instead of throwing ISA, you can have a test method to return a boolean to indicate if the default trace file should be read.
> Instead of running java.base from the runtime, you can use Runtime.version() instead and I think comparing Version::major should be adequate.
Sure, I've changed to compare Runtime.Version.major and minor. While
minor differences should be fine, the plugin depends on internals that
are subject to change in minor
releases. To support experimentation and testing I've added a
ignore-version suboption to override this.
> This change disables this default setting entirely if the image being created is not the same version as this plugin (defaultSpecies and defaultInvokers, etc). Is it intended?
Yes, this is intended, as we can't guarantee the code generated using
one version of jlink will be compatible with the next; the format of the
trace is also subject to change.
> In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It’s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It’s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored.
I think a warning is reasonable in all cases: Using a different version
of jlink than the java.base you're linking will lose some optimizations
and the user would be none the wiser as to why, verbosity helps avoid
More verbosity control would be great, but that seems like a good fit
for a JDK 10 RFE.
More information about the jigsaw-dev