Hi Mandy,
On 02/15/2017 08:09 PM, Mandy Chung wrote:
On Feb 15, 2017, at 9:12 AM, Claes Redestad <[email protected]> wrote:
Hi,
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
releases.
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
surprises.
http://cr.openjdk.java.net/~redestad/8175026/jdk.02/
More verbosity control would be great, but that seems like a good fit
for a JDK 10 RFE.
Thanks!
/Claes
Mandy
