Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8223400

Replace some enums with static const members in hotspot/runtime



    • b20



        4As per comments suggestions in JDK-8213416 splitting up the task.
        Creating this new JDK-8223400 task to cover the requirements in hotspot/runtime.
        Keeping old JDK-8213416 for changes in hotspot/compiler.

        # [ Copying the Description details from 8213416 ] -

        In JDK-8211073, we tried to enable -Wextra for gcc on hotspot.
        This triggers the "enumeral and non-enumeral type in conditional expression" warning for eight methods in hotspot.
        The code typically looks like this:
           types[index] = (tag.is_unresolved_klass()) ? JVM_CONSTANT_Class : tag.value();
        but tag.value() returns an unsigned char, and JVM_CONSTANT_Class is an enum.
        Kim Barrett suggested to rewrite those enums to be static const members instead.
        This would allow us to enable -Wextra, without having to add casts to the enums in the ?: clauses.
        The enums in question that triggers this warning are:
          * CompLevel_highest_tier
          * Op_RegFlags
          * NO_HASH
          * JVM_CONSTANT_Class
        I'm also getting the compiler warning for Klass::_lh_array_tag_obj_value,
        but from my cursory reading of the source code it is not clear to me that any of them is an enum..?
        But apparently the compiler believes this, so it's probably correct.

        # [ related comments extracts from 8213416 ] -

        >> Vladimir Kozlov added a comment - 2018-12-03
        David H. only complained about NO_HASH which we can fix.
        We can also fix CompLevel_highest_tier usage - should use CompLevel type everywhere.
        But I would not touch Op_RegFlags - I don't want to complicate its construction and we have a lot of places where Op_<reg> are used as uint.
        I would only fix places where it is used as int to make sure it is used as uint everywhere.
        JVM_CONSTANT_Class should be decided by runtime group.

        >> Magnus Ihse Bursie added a comment - 2018-12-03
        It might be that this bug needs to be split up, yes.
        I might have lumped together too different issues from too different parts of hotspot.
        Feel free to solve this by splitting out stuff that you do not want to fix into a separate issue, and fix whatever you can.
        In any case, deferring to 13 is fine, since I'll not be able to fix the blocked bug in 12 anyway.

        So based on comments, for now to support the blocked JDK-8211073
         - changes related to CompLevel_highest_tier, NO_HASH, Op_RegFlags to be covered in JDK-8213416
         - changes related to JVM_CONSTANT_Class to be covered here in JDK-8223400.


          Issue Links



                ihse Magnus Ihse Bursie
                rraghavan Rahul Raghavan
                0 Vote for this issue
                5 Start watching this issue