[8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result

[Severin Gehwolf]

On Tue, 2020-05-12 at 18:18 +0100, Andrew Hughes wrote:
> 
> On 12/05/2020 09:53, Severin Gehwolf wrote:
> 
> snip...
> 
> > > In code,
> > > 
> > > unsigned int jdk_version;
> > > unsigned int update_version : 16;
> > > unsigned int reserved1 : 16;
> > > unsigned int reserved2;
> > > 
> > > or, if we're wary about losing the name special_update_version, we could
> > 
> > special_update_version seems at least be referenced in code. So we
> > would have to change those references. Given that, I'd go with reducing
> > reserved1 as that doesn't seem to be used.
> 
> Yeah, can you tell I thought better of this, even as I was writing the
> e-mail? ;-)

:)

> > > shrink reserved1:
> > > 
> > > unsigned int jdk_version;
> > > unsigned int update_version : 16;
> > > unsigned int special_update_version : 8;
> > > unsigned int reserved1 : 8;
> > > unsigned int reserved2;
> > 
> > This is what webrev 03 does:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/
> > 
> > Does that look OK to you?
> 
> This looks ok to me.

Thanks for the review!

> I hadn't realised reserved1 was actually not reserved, but used for the
> build number. I think it's still fine though, as I can't recall seeing
> the build number go over 255 pre-GA, never mind in an update release. If
> we've done over 255 weeks of build promotions before a release, we have
> other problems.

This sounds strange. Where do you see reserved1 being accessed as build
number? For jdk_version_info the build number is part of the 32 bit
unsigned int 'jdk_version_info.jdk_version'. That remains unchanged.
What we *do* change with is bit-fields after the jdk_version integer.

It's jvm_version_info.jvm_version which includes unused bits as part of
the major, minor, micro, build quadruplet. micro is unused there, hence
the proposal that we extend minor (the JDK update version) so that it
can fit up to a max of 2^16-1. It beats me who came up with those weird
conventions.

> Maybe a rename is in order as part of this. I can't see reserved1
> referenced anywhere in the codebase, and it's actually confusing that
> all the extraction code actually refers to it as the build number.
> reserved2 could then simply become reserved.

I don't think that makes sense and would rather avoid more churn. Am I
missing something?

Thanks,
Severin