{"push_id":549789329,"size":5,"distinct_size":5,"ref":"refs/heads/opt/inlining","head":"2ede7944aafeb98d70c802032bb5c391c6dc830e","before":"a0e236177360031b815963e05bc5585c2da95a4d","commits":[{"sha":"c76f91e5bcf1e6c71332e491834ab9d562279848","author":{"email":"c4c4cd0781e8a49d848921386970d334ffda1135@gmail.com","name":"Lukas Rytz"},"message":"Find instructions that would cause an IllegalAccessError when inlined\n\nSome instructions would cause an IllegalAccessError if they are\ninlined into a different class.\n\nBased on Miguel's implementation in 6efc0528c6.","distinct":true,"url":"https://api.github.com/repos/lrytz/scala/commits/c76f91e5bcf1e6c71332e491834ab9d562279848"},{"sha":"b8de9f28c994be74173b89a1fab7db7c3188d1fe","author":{"email":"c4c4cd0781e8a49d848921386970d334ffda1135@gmail.com","name":"Lukas Rytz"},"message":"Tools to perform inlining.\n\nThe method Inliner.inline clones the bytecode of a method and copies\nthe new instructions to the callsite with the necessary modifications.\nSee comments in the code.\n\nMore tests are added in a later commit which integrates the inliner\ninto the backend - tests are easier to write after that.","distinct":true,"url":"https://api.github.com/repos/lrytz/scala/commits/b8de9f28c994be74173b89a1fab7db7c3188d1fe"},{"sha":"b40618eb410b8e0784b7a05ada0cb62f303df9c3","author":{"email":"c4c4cd0781e8a49d848921386970d334ffda1135@gmail.com","name":"Lukas Rytz"},"message":"Reuse the same compiler instance for all tests in a JUnit class\n\nNote that JUnit creates a new instance of the test class for running\neach test method. So the compiler instance is added to the companion.\nHowever, the JVM would quickly run out of memory when running multiple\ntests, as the compilers cannot be GCd. So we make it a `var`, and set\nit to null when a class is done. For that we use JUnit's `@AfterClass`\nwhich is required to be on a static method. Therefore we add a Java\nclass with such a static method that we can extend from Scala.","distinct":true,"url":"https://api.github.com/repos/lrytz/scala/commits/b40618eb410b8e0784b7a05ada0cb62f303df9c3"},{"sha":"928043ff5efe77e357b05088ff2d5ad88fbb7044","author":{"email":"c4c4cd0781e8a49d848921386970d334ffda1135@gmail.com","name":"Lukas Rytz"},"message":"Build a call graph for inlining decisions\n\nInlining decisions will be taken by analyzing the ASM bytecode. This\ncommit adds tools to build a call graph representation that can be\nused for these decisions.\n\nThe call graph is currently built by considering method descriptors of\ncallsite instructions. It will become more precise by using data flow\nanalyses.","distinct":true,"url":"https://api.github.com/repos/lrytz/scala/commits/928043ff5efe77e357b05088ff2d5ad88fbb7044"},{"sha":"2ede7944aafeb98d70c802032bb5c391c6dc830e","author":{"email":"c4c4cd0781e8a49d848921386970d334ffda1135@gmail.com","name":"Lukas Rytz"},"message":"Integrate the inliner into the backend pipeline\n\nThe current heuristics are simple: attempt to inline every method\nannotated `@inline`. Cycles in the inline request graph are broken\nin a determinisitc manner. Inlining is then performed starting at the\nleaves of the inline request graph, i.e., with those callsites where\nthe target method has no callsites to inline.\n\nThis expansion strategy can make a method grow arbitrarily. We will\nmost likely have to add some thresholds and / or other measures to\nprevent size issues.","distinct":true,"url":"https://api.github.com/repos/lrytz/scala/commits/2ede7944aafeb98d70c802032bb5c391c6dc830e"}]}