1. 11 Feb, 2015 3 commits
    • tony.ys_liu's avatar
      am 227dfb0a: Fix false alarm on thread suspend timeout · afc4ef58
      tony.ys_liu authored
      * commit '227dfb0a':
        Fix false alarm on thread suspend timeout
      afc4ef58
    • tony.ys_liu's avatar
      Fix false alarm on thread suspend timeout · 227dfb0a
      tony.ys_liu authored
      Root cause:
        CLOCK_REALTIME will jump backward/forward when system time-of-day clock is changed.
        It implies now_abs_ts will jump a lot across end_abs_ts.
        Then, it makes a false alarm (process crash) on thread suspend timeout when doing ComputeRelativeTimeSpec.
      
            if (ComputeRelativeTimeSpec(&rel_ts, end_abs_ts, now_abs_ts)) {
              return false;  // Timed out.
            }
      
      Solution:
        Use CLOCK_MONOTONIC instead
      
      Bug: 19296054
      Bug: 19268145
      
      (cherry picked from commit 071e48ec)
      
      Change-Id: I68fa5afda75e53373e836dd7779821aeb6f1bd46
      (cherry picked from commit 7d9ad8bb)
      227dfb0a
    • Andreas Gampe's avatar
      ART: Allow class-loading during deopt · 44fb719e
      Andreas Gampe authored
      When deoptimizing, we might touch code that uses unloaded classes.
      
      Bug: 19290147
      Change-Id: I5776f08ba366e9742336caba0d6af85f00629afc
      44fb719e
  2. 06 Feb, 2015 1 commit
    • tony.ys_liu's avatar
      Fix false alarm on thread suspend timeout · 7d9ad8bb
      tony.ys_liu authored
      Root cause:
        CLOCK_REALTIME will jump backward/forward when system time-of-day clock is changed.
        It implies now_abs_ts will jump a lot across end_abs_ts.
        Then, it makes a false alarm (process crash) on thread suspend timeout when doing ComputeRelativeTimeSpec.
      
            if (ComputeRelativeTimeSpec(&rel_ts, end_abs_ts, now_abs_ts)) {
              return false;  // Timed out.
            }
      
      Solution:
        Use CLOCK_MONOTONIC instead
      
      Bug: 19296054
      
      (cherry picked from commit 071e48ec)
      
      Change-Id: I68fa5afda75e53373e836dd7779821aeb6f1bd46
      7d9ad8bb
  3. 31 Jan, 2015 1 commit
  4. 28 Jan, 2015 1 commit
    • Mathieu Chartier's avatar
      Force set resolved method for static invokes · 72d72ef5
      Mathieu Chartier authored
      For static invokes, we may dispatch to the static method in the
      superclass but resolve using the subclass. To prevent getting slow
      paths on each invoke, we force set the resolved method for the
      super class dex method index if we are in the same dex file.
      
      Added test.
      
      Bug: 19175856
      (cherry picked from commit e4a91bbe)
      Change-Id: I26f8644a7f725f5c2dc2a94a8e9578f573792507
      72d72ef5
  5. 26 Jan, 2015 1 commit
  6. 23 Jan, 2015 5 commits
    • Andreas Gampe's avatar
    • Jeff Hao's avatar
    • Andreas Gampe's avatar
      ART: On shutdown, only warn on mutex contention · c0440f69
      Andreas Gampe authored
      Do not abort, as daemon threads may still be active.
      
      Bug: 17894429
      Change-Id: I7c1d50ff8d4a5e150279e703a69c8f2f1d423e6b
      c0440f69
    • Sebastien Hertz's avatar
      Fix exception handling during deoptimization · 90a33595
      Sebastien Hertz authored
      When interpreting a deoptimized shadow frame, we may start with a
      pending exception thrown by a previous deoptimized shadow frame (from
      a previous invoke). Therefore, we need to handle it before executing
      any instruction, otherwise we execute incorrect code.
      
      Because we need the DEX pc of the throwing instruction to find a
      matching catch handler, we initialize deoptimized shadow frames with
      the current DEX pc at the time the stack is deoptimized.
      When we are about to interpret a deoptimized shadow frame, we need to
      update the shadow frame with the DEX pc of the next instruction to
      interpret. There are three cases:
      - if there is no pending exception, this is the instruction following
      the current one.
      - if there is a pending exception and we found a matching catch
      handler, this is the first instruction of this handler.
      - if there is a pending exception but there is no matching catch
      handler, we do not execute the deoptimized shadow frame and continue
      to its caller.
      
      The verifier now fails when a method starts with a move-exception
      instruction. Indeed we cannot start executing a method with a pending
      exception.
      
      Bug: 19057915
      Bug: 19041195
      Bug: 18607595
      
      (cherry picked from commit 270a0e16)
      
      Change-Id: Ib4fdd0ad704b4f2369d229737c9cc77f559cea55
      90a33595
    • Jeff Hao's avatar
      Allow preopted apps to have sharpened calls for non-x86 architectures. · 2397ad72
      Jeff Hao authored
      Bug: 19100762
      
      Change-Id: Iefd4265cb7864cdaa12c1f9e44bfaa5aa4fb93ec
      2397ad72
  7. 22 Jan, 2015 2 commits
  8. 21 Jan, 2015 1 commit
  9. 20 Jan, 2015 1 commit
    • Andreas Gampe's avatar
      ART: Curb dex2oat verbosity · aa3eff99
      Andreas Gampe authored
      Only print dedupe collisions in a debug build or on verbose logging.
      
      Bug: 19082662
      
      (cherry picked from commit 8d295f8f)
      
      Change-Id: I08bd04a453d95b6dba6cf6955b5741cd97daf480
      aa3eff99
  10. 17 Jan, 2015 1 commit
    • Sebastien Hertz's avatar
      JDWP: fix breakpoint for method in the image · 7f418db8
      Sebastien Hertz authored
      When we set a breakpoint in a compiled method, we deoptimize it by
      changing its entrypoint so it is executed with the interpreter.
      However, methods in the image can be called with their direct code
      pointer, ignoring the updated entrypoint. In that case, the method
      is not executed with the interpreter and we miss the breakpoint.
      
      This CL avoids that situation by forcing a full deoptimization so
      everything runs with the interpreter. However, if the image has been
      compiled in PIC mode, we keep using selective deoptimization because
      direct code pointer is not used in this mode.
      
      Bug: 17965285
      
      (cherry picked from commit 6963e443)
      
      Change-Id: I9bf738f89b9eb6d18733503216b376b8a1d181f5
      7f418db8
  11. 16 Jan, 2015 1 commit
    • tony.ys_liu's avatar
      Fix infinite loop in GenerateIdentityHashCode · b34d505b
      tony.ys_liu authored
      Root Cause:
        If no one changes the seed, it will become infinite loop due to below condition
          (expected_value & LockWord::kHashMask) == 0
      
      Solution:
        Changes the seed before entering the next loop
      
      Added test.
      
      Bug: 19046417
      
      (cherry picked from commit 7380c317)
      
      Change-Id: I7d1c377dd1bda780681514b24d61ebc776bc80ab
      b34d505b
  12. 15 Jan, 2015 4 commits
  13. 14 Jan, 2015 4 commits
    • Andreas Gampe's avatar
    • Andreas Gampe's avatar
      ART: Simple structural class check · 15a33b3f
      Andreas Gampe authored
      Adds a simple check to class-loading when the embedded dex file in
      an oat file and the dex file on the class path where we found the
      class do not match.
      
      We require that the number of methods and fields do not change, as
      that will almost certainly mean that quickened and other compiled
      offsets are wrong now. This is a reasonably lightweight change, but
      we should investigate a full comparison including name and type of
      members.
      
      Bug: 17937814
      Bug: 18708951
      Change-Id: Icb9638bebd369ab23822817f4a97c8dd8625fea5
      15a33b3f
    • Vladimir Marko's avatar
      Fix wide volatile IGET/IPUT on ARM without atomic ldrd/strd. · e7227c62
      Vladimir Marko authored
      If ldrd/strd isn't atomic, IPUT_WIDE uses ldrexd+strexd and
      we need to record the safepoint for the ldrexd rather than
      strexd. IGET_WIDE was simply missing the memory barrier.
      
      Bug: 18993519
      
      (cherry picked from commit ee5e273e)
      
      Change-Id: I4e9270b994f413c1a047c1c4bb9cce5f29e42cb4
      e7227c62
    • Nicolas Geoffray's avatar
      Add a test for our NPE checks. · ce0724c0
      Nicolas Geoffray authored
      (cherry picked from commit 5f16c883)
      
      Change-Id: I0b216fb868ed56d30103fe7843a7eb0169b0b28b
      ce0724c0
  14. 12 Jan, 2015 1 commit
    • Sebastien Hertz's avatar
      JDWP: allow VirtualMachine.Resume on partial suspension · 66516ac4
      Sebastien Hertz authored
      Allows to resume multiple threads with a single VirtualMachine.Resume
      command. When some threads are suspended for an event by the debugger
      with a suspend count of 1 (other threads are running), a debugger can
      resume them all this way.
      
      Bug: 18924933
      
      (cherry picked from commit f9d233da)
      
      Change-Id: I948c3b50d43693e86ae31e0928a33a467328583f
      66516ac4
  15. 06 Jan, 2015 5 commits
  16. 22 Dec, 2014 2 commits
  17. 20 Dec, 2014 3 commits
  18. 19 Dec, 2014 3 commits