...
In general we'll use the process in https://openjdk.java.net/projects/jdk-updates/approval.html.
We do not yet have much experience with our test systems, so for the first couple of quarters we should be fairly cautious. Later on we can be more adventurous, but for now it's mostly "bug fixes only".
All fixes that significantly improve stability, security or performance and do not change behavioural compatibility [1]will be considered for jdk8u. To use the language of the JDK 6 project, by default such fixes are assumed to be applicable to jdk8u, especially if having "soaked" in later JDK releases for a time without incident. By "significant" I mean any bug that affects runtime behaviour in a way that either produces incorrect results, poor performance, or crashes the VM, especially TCK failures. Failures that are due solely to bizarre or unreasonable combinations of -XX: command-line parameters probably don't reach the bar of significance, and fixing them will carry a non-zero risk of breaking something, so we should err on the size of caution. For now it's mostly "bug fixes only".
Build failures on all platforms, including 32-bit ones, are assumed to be applicable. Also, there is a good deal of C++ code with Undefined Behaviour in HotSpot, and such bugs tend to cause failures with more recent C++ compilers. While all UB fixes may be applied to jdk8u, they should be submitted to the current jdk development tree first.
...