JDK-8198908 : Add JVM support for preview features
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-03-01
  • Updated: 2019-06-20
  • Resolved: 2018-04-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b10Fixed
Related Reports
Blocks :  
JDK-8199193 - jshell tool: Add support for preview features
CSR :  
JDK-8200440 - Add JVM support for preview features
Relates :  
CODETOOLS-7902132 - JTReg compiled .jasm files end up with incorrect class file versions
Relates :  
JDK-8195734 - JEP 12: Preview Features
Relates :  
JDK-8198793 - Add launcher support for preview features
Relates :  
JDK-8200338 - 4.1: Restrict the legal values of ClassFile.minor_version
Description
See if any changes are needed within the JVM for support of incubating features which may have changes in classfile formats or constant pool entries. This is based on the current Java version and the incubating option flag

See also https://bugs.openjdk.java.net/browse/JDK-8195734
Comments
JVMS changes to restrict unsupported minor version numbers will be handled by JDK-8200338.
27-03-2018
The above (confidential) webrev now has support for -Xlog:class+preview. It logs the following: > $JAVA_TEST/bin/java -Xlog:class+preview --enable-preview myPreviewClass [0.578s][info][class,preview] Loading preview feature type myPreviewClass ...
16-03-2018
A suggestion. Rather than the global statement about: If a class file's use of a preview VM feature of Java SE $N causes an exception during loading, linking, or execution, then the JVM implementation must indicate that the exception is due to an preview VM feature of Java SE $N. I think there might be a couple of alternatives the JVM could explore. Note that javac will print a message such as "Note: some input files use a preview language feature" - globally for a given source file. I would highly recommend that if the JVM were to create an hs_err file (due to crashing mostly) that we should record the use of a preview JVM feature. The simplest way to do this would be to print a message such as "Note: some classfiles use a preview VM feature". That would potentially help sustaining and is information that we have.
16-03-2018
We could report whether any class files were loaded with a minor version that had all 16 bits set. Also, we could add a logging capability that prints a message when loading a preview class. (-Xlog:class+load+preview ?)
16-03-2018
>> You mean to confirm that a preview feature was actually used? Yes.
16-03-2018
Yes we should report that "--enable-preview" is active, the same way we report use of WhiteBox.
16-03-2018
> We could report whether any class files were loaded with a minor version that had all 16 bits set. You mean to confirm that a preview feature was actually used? Logging is good.
16-03-2018
If the command-line flag has moved from the launcher to the JVM, then --enable-preview should up in the flags in the hs_err log without extra work. I realized the back of my mind is slow to adopt the concept that "preview" means "stable" and requesting user feedback. So there is no reason to expect instability due to this feature over others. I think Harold's logging suggestion would give the information folks need - and make sure it is at a logging level that is off by default. Thanks for suggesting that.
16-03-2018
[~dholmes] Thank you, I see what you mean: there is nothing more for this JBS issue to do until there is a specific preview VM feature that wishes to govern the loading/linking/execution of a vNN.65535 class file.
13-03-2018
All I am saying is that in response to: "If a class file's use of a preview VM feature of Java SE $N causes an exception during loading, linking, or execution, then the JVM implementation must indicate that the exception is due to an preview VM feature of Java SE $N. " it will be up to the feature being implemented to ensure that its own usage is correctly monitored with regards to being a preview feature. There is nothing general-purpose that the VM can do (AFAICS at the moment) that would need to be pushed as part of this specific issue.
13-03-2018
[~dholmes] I agree there is no generic code that can do this, but the condy feature is implemented in HotSpot, and I expect that implementation to be self-aware (that is, aware that it's part of a preview VM feature). If my expectation is fundamentally misguided, can you explain why? I am very keen to avoid talking past each other.
13-03-2018
[~abuckley] I think that reinforces what I was trying to say. The Condy feature would be responsible for self-checking it was being used correctly and identifying mis-use. There's no generic code in the VM that can do this.
13-03-2018
Suppose JEP 309, condy, was proposed to target JDK 11 as a preview VM feature. You could expect three main sub-features in a v55.65535 class file: 1. CONSTANT_Dynamic entries in the constant_pool table. 2. ldc being able to refer to a symbolic reference to a dynamically-computed constant derived from (1). 3. Resolution of a symbolic reference to a dynamically-computed constant, either in the service of an ldc or for a static argument of a bootstrap method. Then: - Without --enable-preview (so v55.65535 is eagerly rejected, and we only have to worry about v55.0 class files): (1) and (2) are illegal in a v55.0 class file (normal CFE; no mandate from JEP 12 to highlight that they're preview artifacts; align with javac where detecting a preview language feature without --enable-preview may be impossible). (3) is moot (the run-time constant pool will have no such symbolic references). - With --enable-preview (so v55.65535 is allowed): (1) is legal in v55.65535, so a malformed CONSTANT_Dynamic entry should cause a CFE whose message indicates a preview artifact. (2) is legal in v55.65535, so a malformed ldc instruction should cause a VerifyError whose message indicates a preview artifact. (3) is legal, so if a v55.65535 class file was loaded and verified but its run-time constant pool contains a symbolic reference to a dynamically-computed constant that could not be resolved, then the ICCE should have a message indicating a preview artifact.
13-03-2018
Harold: that sounds like the preview feature must ensure that all exceptions from it are identified as such. AFAIK the VM has no way to tell that a preview feature is in use, so it can not tell that an exception occurred due to use of such a preview feature.
13-03-2018
This statement in JEP 12 requires additional JVM work: If a class file's use of a preview VM feature of Java SE $N causes an exception during loading, linking, or execution, then the JVM implementation must indicate that the exception is due to an preview VM feature of Java SE $N.
12-03-2018
+1 with Alan, Pack200 is one such tool which parses class-files.
08-03-2018
Once this issue is a bit further along, we should create issues for the other places in the JDK that might need to be aligned (esp. with class file parsing).
06-03-2018
We'll need to create a spec bug to change the version number constraints when the requirements are clear. My two cents: we can carve out a really narrow range of prohibited version numbers (55.65535, 56.65535, ...). But I'd rather make a breaking change: enumerate all the actually-used version numbers since 1.0 (something like 45.*, 46.0, 47.0, ..., 55.0), and reject the rest.
05-03-2018
JEP 12 says the following: A class file denotes that it depends on the preview VM features of Java SE $N by having a major_version item that corresponds to Java SE $N and a minor_version item that has all 16 bits set. ... A JVM implementation for Java SE $N must not define a class file that depends on the preview VM features of another platform version, even if the JVM implementation would otherwise understand the class file's version. ... In essence, Java SE $N+1 does not claim backwards compatibility with the preview features of Java SE $N. ------------------------------------------------------------------------------------------------------------------ Implementation of the above text will require a small change to method is_supported_version() in classFileParser.cpp. The method should be changed to return FALSE if the current class's major version is less than JVM_CLASSFILE_MAJOR_VERSION and the current class's minor version has all 16 bits set.
02-03-2018