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

assert(is_double_stack() && !is_virtual()) failed: type check

    XMLWordPrintable

Details

    • b13
    • generic
    • generic

    Description

      ADDITIONAL SYSTEM INFORMATION :
      A part of relevant code is in java/hotspot/cpu/x86.


      A DESCRIPTION OF THE PROBLEM :
      Hi,

      I'm not sure this is the appropriate place to report this bug. If not please let me know where to report.

      The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
      > __ move(addr, tmp);
      This seems valid because the method computes the effective address so that `addr` must be a register operand beforehand. However, the this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)`
      is compiled to a memory-to-register move, ie., `move [stack:xx|L], [rxxrxx|J]`. This causes an assertion failure because a memory-to-register move requires their arguments to have the same size.

      The following replace may fix:
      - __move(addr, tmp);
      + if (addr->is_oop()) {
      + LIR_Opr tmp2 = gen->new_register(T_OBJECT);
      + __ move(addr, tmp2);
      + __ move(tmp2, tmp);
      + } else
      + __ move(addr, tmp);



      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      This assertion failure happened in reality when I extended the CardTableBarrierSetC1 and called a runtime function, clobbering registers, before calling post_barrier.


      FREQUENCY : always


      Attachments

        Issue Links

          Activity

            People

              fmatte Fairoz Matte
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: