)]}'
{
  "log": [
    {
      "commit": "79d8fa7c52c1810d4618c9bd1d43994be5abb53d",
      "tree": "411a76dec2adf4139328d5e607b498b72c9aa2af",
      "parents": [
        "acac09dad3d5aa3922e6cdf54ff2e4fa6f176484"
      ],
      "author": {
        "name": "Igor Murashkin",
        "email": "iam@google.com",
        "time": "Tue Apr 18 09:37:23 2017 -0700"
      },
      "committer": {
        "name": "Igor Murashkin",
        "email": "iam@google.com",
        "time": "Thu May 18 14:14:13 2017 +0000"
      },
      "message": "optimizing: Build HConstructorFence for HNewArray/HNewInstance nodes\n\nAlso fixes:\n* LSE, code_sinking to keep optimizing new-instance if it did so before\n* Various tests to expect constructor fences after new-instance\n\nSidenote: new-instance String does not get a ConstructorFence; the\nspecial StringFactory calls are assumed to be self-fencing.\n\nMetric changes on go/lem:\n* CodeSize -0.262% in ART-Compile (ARMv8)\n* RunTime -0.747% for all (linux-armv8)\n\n(No changes expected to x86, constructor fences are no-op).\n\nThe RunTime regression is temporary until art_quick_alloc_* entrypoints have their\nDMBs removed in a follow up CL.\n\nTest: art/test.py\nBug: 36656456\nChange-Id: I6a936a6e51c623e1c6b5b22eee5c3c72bebbed35\n"
    },
    {
      "commit": "d01745ef88bfd25df574a885d90a1a7785db5f5b",
      "tree": "058eb1593dbb0fe8a8e26b901909bec8aa01d474",
      "parents": [
        "a57c334075b193de9690fff97acf6c1b1d1283fc"
      ],
      "author": {
        "name": "Igor Murashkin",
        "email": "iam@google.com",
        "time": "Wed Apr 05 16:40:31 2017 -0700"
      },
      "committer": {
        "name": "Igor Murashkin",
        "email": "iam@google.com",
        "time": "Tue May 02 09:45:45 2017 -0700"
      },
      "message": "optimizing: constructor fence redundancy elimination - remove dmb after LSE\n\nPart one of a few upcoming CLs to optimize constructor fences.\n\nThis improves load-store-elimination; all singleton objects that are not\nreturned will have their associated constructor fence removed.\n\nIf the allocation is removed, so is the fence. Even if allocation is not\nremoved, fences can sometimes be removed.\n\nThis change is enabled by tracking the \"this\" object associated with the\nconstructor fence as an input. Fence inputs are considered weak; they do not keep\nthe \"this\" object alive; if the instructions for \"this\" are all deleted,\nthe fence can also be deleted.\n\nBug: 36656456\nTest: art/test.py --host \u0026\u0026 art/test.py --target\nChange-Id: I05659ab07e20d6e2ecd4be051b722726776f4ab1\n"
    },
    {
      "commit": "f8b3b8bc37fb04d8ae113ae6bfcf4de2f5a700d4",
      "tree": "cee02ae8f42e413e2d6af2140cd2f08e6ea34e6d",
      "parents": [
        "8b0e9b87ab6e54237b2d1e101b8cce7ea6443238"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Thu Feb 04 19:46:56 2016 +0000"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Wed Feb 10 10:12:22 2016 +0000"
      },
      "message": "Try to substitute constructor chains for IPUTs.\n\nMatch a constructor chain where each constructor either\nforwards some or all of its arguments to the next (i.e.\nsuperclass constructor or a constructor in the same class)\nand may pass extra zeros (of any type, including null),\nfollowed by any number of IPUTs on \"this\", storing either\narguments or zeros, until we reach the contructor of\njava.lang.Object.\n\nWhen collecting IPUTs from the constructor chain, remove\nany IPUTs that store the same field as an IPUT that comes\nlater. This is safe in this case even if those IPUTs store\nvolatile fields because the uninitialized object reference\nwasn\u0027t allowed to escape yet. Also remove any IPUTs that\nstore zero values as the allocated object is already zero\ninitialized.\n\n(cherry picked from commit 354efa6cdf558b2331e8fec539893fa51763806e)\n\nChange-Id: I691e3b82e550e7a3272ce6a81647c7fcd02c01b1\n"
    },
    {
      "commit": "0d11ffe0d59170903695b94c9af8bbadad59ebfe",
      "tree": "cc120789d31f6ed08be24cedf17bcb9b55c4d134",
      "parents": [
        "f1e2b4dd9238d85d041f47b6bd853babe0a53c85"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Tue Feb 02 11:10:16 2016 +0000"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Tue Feb 02 11:23:27 2016 +0000"
      },
      "message": "Optimizing: Do not depend on sharpening in test 569.\n\nThe sharpening may or may not remove the ArtMethod*\nparameter, so the test must not depend on its absence.\nThis fixes the test 569 checker test on mips/mips64.\n\nChange-Id: Ibee88d3602778006558caf33cf69e7c419918699\n"
    },
    {
      "commit": "be10e8e99a78caae01fb65769218800d465144ae",
      "tree": "cfa5cd3264137febdba6e49cae0393c779c6439c",
      "parents": [
        "fa72bf1823a39b43552fa1b9ae572023830a4ac1"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Fri Jan 22 12:09:44 2016 +0000"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Thu Jan 28 18:13:53 2016 +0000"
      },
      "message": "Optimizing: Try pattern substitution when we cannot inline.\n\nChange-Id: I7c01f4494bac8498accc0f087044ec509fee4c98\n"
    }
  ]
}