)]}'
{
  "log": [
    {
      "commit": "ba938cbb8d73a0dcf151dfaec4662496da6afdbf",
      "tree": "09ad41fc5851a22e8c11935edc83c7ece546f856",
      "parents": [
        "763d5fb2f83d9c93b5b764533005865a3d1034e1"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Feb 03 14:47:55 2012 -0800"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Feb 03 15:02:55 2012 -0800"
      },
      "message": "Make the compiler threadsafe\n\nThe compiler inherited a simple memory management scheme that\ninvolved malloc\u0027ng a clump of memory, allocating out of that\nclump for each unit of compilation, and then resetting after\nthe compilation was complete.  Simple \u0026 fast, but built with the\nexpectation of a single compiler worker thread.\n\nThis change moves the memory allocation arena into the\nCompilationUnit structure, and makes it private for each method\ncompilation.  Unlike the old scheme, allocated memory is returned\nto the system following completion (whereas before it was reused\nfor the next compilation).\n\nAs of this CL, each compilation is completely independent.\n\nThe changes involved were mostly mechanical to pass around the\ncUnit pointer to anything which might need to allocate, but the\naccretion of crud has moved me much closer to the point that\nall of this stuff gets ripped out and replaced.\n\nChange-Id: I19dda0a7fb5aa228f6baee7ae5293fdd174c8337\n"
    },
    {
      "commit": "5abfa3ea35781464df8fae60aaf03f48a295e965",
      "tree": "3db19d0ecfc1031f86d77964de636ec45d4ba690",
      "parents": [
        "6c7d244058b74cdd61533968dd6cddd7003d2671"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Tue Jan 31 17:01:43 2012 -0800"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Thu Feb 02 15:56:41 2012 -0800"
      },
      "message": "Compiler tuning\n\nSignificant reduction in memory usage by the compiler.\n    o Estimated sizes of growable lists to avoid waste\n    o Changed basic block predecessor structure from a growable bitmap\n      to a growable list.\n    o Conditionalized code which produced disassembly strings.\n    o Avoided generating some dataflow-related structures when compiling\n      in dataflow-disabled mode.\n    o Added memory usage statistics\n    o Eliminated floating point usage as a barrier to disabling expensive\n      dataflow analysis for very large init routines.\n    o Because iterating through sparse bit maps is much less of a concern now,\n      removed earlier hack that remembered runs of leading and trailing\n      zeroes.\n\nAlso, some general tuning.\n    o Minor tweaks to register utilties\n    o Speed up the assembly loop\n    o Rewrite of the bit vector iterator\n\nOur previous worst-case method originally consumed 360 megabytes, but through\nearlier changes was whittled down to 113 megabytes.  Now it consumes 12 (which\nso far appears to close to the highest compiler heap usage of anything\nI\u0027ve seen).\n\nPost-wipe cold boot time is now less than 7 minutes.\n\nInstallation time for our application test cases also shows a large\ngain - typically 25% to 40% speedup.\n\nSingle-threaded host compilation of core.jar down to \u003c3.0s, boot.oat builds\nin 17.2s.  Next up: multi-threaded compilation.\n\nChange-Id: I493d0d584c4145a6deccdd9bff344473023deb46\n"
    },
    {
      "commit": "5b53710b4abcf8f35c91a963a475b72cb34757e6",
      "tree": "9f10f49fd09798a8f07ebffb4ee357c135e56f9f",
      "parents": [
        "cf044318c5638df0c400b731e94fab948ebd5ccb"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Tue Jan 17 17:33:47 2012 -0800"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Tue Jan 24 06:00:32 2012 -0800"
      },
      "message": "Dataflow analysis rework\n\nRework key portions of the dataflow analysis code to avoid the\nmassive slowdowns we\u0027re seeing with methods containing more than\n20,000 basic blocks.\n\nAdd a somewhat hacky lookup cache in front of findBlock.  Later\nwe\u0027ll want to rework the \"GrowableList\" mechanism to incorporate\nthis properly.\n\nAdd memory to the bit vector utilities to speed up the iterators\nfor large sparse vectors. (Similarly, in the future we\u0027ll want\nto include a rewrite of the home-grown bit-vector manipluation\nutilites to be better with large ones).\n\nWith this CL, compilation speed on the degenerate cases is \u003e 10x\nfaster.  Compilation of typically-sized methods will see a smallish\nimprovement.\n\nChange-Id: I7f086c1229dd4fe62f0a5fc361234bf204ebc2b1\n"
    },
    {
      "commit": "11d1b0c31ddd710d26068da8e0e4621002205b4b",
      "tree": "8d9c9c0dd5741214466775b86069032d609fd91c",
      "parents": [
        "bbdb1437f55948e5395b4dcb306e25605539a444"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Mon Jan 23 16:57:47 2012 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Mon Jan 23 17:26:10 2012 -0800"
      },
      "message": "Reduce namespace pollution.\n\nThis leaves us with just the mspace stuff and three libdex functions to clean\nup. We deliberately expose the JII API, and I don\u0027t think there\u0027s anything we\ncan really do about the art_..._from_code stuff (and at least that starts with\n\"art_\").\n\nChange-Id: I77e58e8330cd2afeb496642302dfe3311e68091a\n"
    },
    {
      "commit": "67bc236a207852d652f6ddeab0a90efc1bd111bb",
      "tree": "eea13fcb90ad8ce5b2b3819fb8caf0281583cd61",
      "parents": [
        "95caa791e560da97363c0c0d22bfda4a7e7377c3"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Tue Oct 11 18:08:40 2011 -0700"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Oct 14 10:54:03 2011 -0700"
      },
      "message": "Register promotion fix\n\nRestructured the type inference mechanism, added lots of DCHECKS,\nbumped the default memory allocation size to reflect AOT\ncompilation and tweaked the bit vector manipulation routines\nto be better at handling large sparse vectors (something the old\ntrace JIT didn\u0027t encounter enough to care).\n\nWith this CL, optimization is back on by default.  Should also see\na significant boost in compilation speed (~2x better for boot.oat).\n\nChange-Id: Ifd134ef337be173a1be756bb9198b24c5b4936b3\n"
    },
    {
      "commit": "6181f79576e4269937b45e4fce8d0d004107e5b9",
      "tree": "1e5970dd4074c9852b10ecfc6bc4f18b89d40dd7",
      "parents": [
        "557e027f86d86f801e1b48055f8116f2d83d3d5c"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Thu Sep 29 11:14:04 2011 -0700"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Thu Sep 29 13:38:10 2011 -0700"
      },
      "message": "Register usage cleanup\n\nI plan to enable some of the old-world basic block optimizations.\nThose care about temp register status, so we needed a bit of\ncleanup on the temp tracking.\n\nChange-Id: I317bce1b91a73ec9589c20ed5bfe00d53994991a\n"
    },
    {
      "commit": "ed3e930109e3f01804ca32cee4afe4f2d4b3f4d8",
      "tree": "41c3ffd3fdade2244b4cd3824c98419edecbca86",
      "parents": [
        "8060925c45cc2607ab92390d7366c6c0cfdfe4bb"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Sep 23 17:34:19 2011 -0700"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Sep 23 18:34:31 2011 -0700"
      },
      "message": "assert to DCHECK conversion\n\nAlso replaced static function defs with a STATIC macro to make normally\nhidden functions visible to DCHECK\u0027s traceback listing).  Additionally,\nadded some portions of the new type \u0026 size inference mechanism (but not\ntaking advantage of them yet).\n\nChange-Id: Ib42a08777f28ab879d0df37617e1b77e3f09ba52\n"
    },
    {
      "commit": "67bf885d62b1473c833bece1c9e0bb624e6ba391",
      "tree": "a6069d30bb0e25d4ed1f19d7a3c2b55c4aef7127",
      "parents": [
        "f4c21c9f6440c3980c47a297519f758796dbc039"
      ],
      "author": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Wed Aug 17 17:51:35 2011 -0700"
      },
      "committer": {
        "name": "buzbee",
        "email": "buzbee@google.com",
        "time": "Fri Aug 19 20:14:15 2011 -0700"
      },
      "message": "Oat compiler integration snapshot.\n\nCleanly compiles, but not integrated.  Old-world dependencies captured\nin hacked-up temporary files \"Dalvik.h\" and \"HackStubs.cc\".\n\nDalvik.h is a placeholder that captures all of the constants, struct\ndefinitions and inline functions the compiler needs.  It largely consists\nof declaration fragments of libdex, Object.h, DvmDex.h and Thread.h.\n\nHackStubs.cc contains empty shells for some required libdex routines.\n\nChange-Id: Ia479dda41da4e3162ff6df383252fdc7dbf38d71\n"
    }
  ]
}