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

Stefan Karlsson stefank at openjdk.org
Mon Jun 27 14:29:40 UTC 2022


On Mon, 27 Jun 2022 14:14:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> 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.

Talked to Albert. He's already created a patch for this, so I retract my objection to this blocking of the PR.

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

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


More information about the serviceability-dev mailing list