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

memnode.cpp,100 assert(consistent,"adr_type must match alias idx") triggered during 1st pass of IGVN

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 5.0u8
    • Fix Version/s: 7
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      This is a defect discovered by the customer using -XX:+CompileTheWorld option. It has never occured in production. Customer can reproduce this using their own testing framework that allows to compile certain specific inline tree. Customer proposes a proactive fix for this issue (see suggested fix)

      --------------------------------------------------------------------
      I have encountered a C2 defect related to IGVN and address types. My
      fix is scheduled for a release, so I'd like to get a review from Sun.

      Symptom in v1.5.0_08:
       memnode.cpp,100 assert(consistent,"adr_type must match alias idx")

      I looked for a possible fix in 6.0, but did not notice anything, and
      didn't see a report in the Sun bug database. I haven't been able to
      test with 6.0 yet.

      The assert occurs during the first pass of IGVN.

      Before IGVN we have an AddP feeding a LoadP.

      958 AddP === _ (NULL) 955 (LoadKlass) 955 (LoadKlass) 957 (ConI)
        [24700958] Klass:klass java/lang/Object: 02dcdba0:NotNull+280 *

      959 LoadP === _ (NULL) 1711 (MergeMem) 958 (AddP)
        @klass java/lang/Object: 02dcdba0:NotNull+280 *, idx=22;
        [24700959] Oop:java/lang/Object:NotNull *

      During IGVN, the base address of 958-AddP is reduced to a constant:

      1714 ConP === 0 (Root)
        [45801714] Klass:precise klass java/lang/String:
      02dc52d8:Constant:exact *

      IGVN pops 959-LoadP before 958-AddP and performs
      MemNode::Ideal_common. Inside MemNode::Ideal_common we have:

      const Type *t_adr = phase->type( address ); <= (klass Object+280)
      const TypePtr *adr_t = adr_type(); <= (klass String:exact+280)
      consistent = phase->C->must_alias(adr_t, alias_idx ); <= false

      -----------------------------------------------------------------------
      Analysis:

      The Object.hashcode native intrinsic loads a vtable entry from the
      object's klass using the inexact klass type "klass java/lang/Object
      +280".

      Type inference later improves the precision of the klass type to
      "klass java/lang/String+280". However, flatten_alias_type() ASSUMES
      that all klass fields beyond the initial Klass fields refer to static
      fields and gives them a unique alias index. But in this case, both
      types refer to the same data so should have the same alias index.

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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              ksoshals Kirill Soshalskiy (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: