RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

[Stefan Karlsson]

On Fri, 24 Jun 2022 00:15:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> `_reference_type` always gets the correct value after the constructor is run. The member initializer list just follows the convention of having all fields set. One could move this field inside the constructor body to ensure this field is set only once.
>
>> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file.
> 
> The mechanism used to compute the correct reftype is purely derived from the
> parser, and to me looks like "parsing". So I think it would be better placed
> with the parser. And that would also remove the need for the two-step
> initialization of the InstanceKlass member.
> 
> With that in mind, I think the file scoped function determine_reference_type
> in instanceRefKlass.cpp should instead be an ordinary public member function
> `ClassFileParser::reference_type() const` (with appropriate adjustment of it's
> implementation), called by the InstanceKlass constructor to initialize
> `_reference_type`.
> 
> Associated with that are some other changes:
> - The new InstanceRefKlass::set_reference_type is no longer needed.
> - The new ClassFileParser::super_reference_type and
> ClassFileParser::is_java_lang_ref_Reference_subclass don't need to be public.
> (Assuming they exist at all after adjustment of ClassFileParser::reference_type.)

> The _reference_type used to be initialized correctly in most cases, but
needed fixing up for a few cases during bootstrapping. With this change it is
never initialized correctly for Reference subtypes and always needs an
initialization kludge for them. That's not an improvement.

I don't agree that this is a kludge. This is quite common in HotSpot, and the code is quite understandable. It's far better than the initialization kludge the code had before this patch.

I'd like to suggest that we go with the proposed patch, and consider the Kim's latest proposal as a follow-up RFE. That way we can make progress on this RFE, and then weigh the pros and cons of this suggestion separately.

-------------

PR: https://git.openjdk.org/jdk/pull/8332