{"push_id":1353243937,"size":132,"distinct_size":2,"ref":"refs/heads/WebAssembly","head":"e44772e54ae2aad5e51528be4d9f2c8c966b39fd","before":"41c48dda03e2c272a112238f528daa2d1df45b28","commits":[{"sha":"538adb975cf7a2ec88393c485e976a2546dc26d0","author":{"name":"Oguz Bastemur","email":"16dc18bfab94db42897450219ec4717f85783177@microsoft.com"},"message":"Fix heap overflow of a global variable\n\ncch does not include sizeof(char16) while pszs->cch includes that","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/538adb975cf7a2ec88393c485e976a2546dc26d0"},{"sha":"fd671436fa3b11336a8bb9ed8d98a73a918d5ec1","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"fix oop jit issue with undefined const this","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/fd671436fa3b11336a8bb9ed8d98a73a918d5ec1"},{"sha":"97febd42d40deb6734de64e144e2df2340ec30f6","author":{"name":"Doug Ilijev","email":"379d7edf6e55b3fef54f2d1667cb1c3b3e94393b@microsoft.com"},"message":"Switch release/1.3 from PRERELEASE to RELEASE mode.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/97febd42d40deb6734de64e144e2df2340ec30f6"},{"sha":"07dde2302b3b5f30579e65e281676649087cccd6","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"should check for tagged number in JITJavascriptString::Is","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/07dde2302b3b5f30579e65e281676649087cccd6"},{"sha":"7b3ac5ff4d9fefb973492522f0b8231a474bbcff","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"explicitly copy profile data for background in-proc jit","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/7b3ac5ff4d9fefb973492522f0b8231a474bbcff"},{"sha":"798870d7d35bde506344b86c64e4df09ae157ad0","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"[MERGE #1688 @MikeHolman] explicitly copy profile data for background in-proc jit\n\nMerge pull request #1688 from MikeHolman:inprocprofiledata\n\nI changed how the profile data is passed for OOP JIT (which will be copied via RPC), however I didn't consider in-proc JIT at the time. This adds back code to copy ld/st elem info for in-proc background jit.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/798870d7d35bde506344b86c64e4df09ae157ad0"},{"sha":"258c0c3ee475ac3ec7998e6bf70e36f7c6f6dac1","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"require non-VS or min of VS2015 Update 3 for constexpr","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/258c0c3ee475ac3ec7998e6bf70e36f7c6f6dac1"},{"sha":"e0b628daa5acc4e90f2d6aea04fbfc6e6435a890","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"[MERGE #1687 @MikeHolman] should check for tagged number in JITJavascriptString::Is\n\nMerge pull request #1687 from MikeHolman:jitstrtagged","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/e0b628daa5acc4e90f2d6aea04fbfc6e6435a890"},{"sha":"4194cdbc96fcd8bd2cbe234f472b6ae6e9eb3bc2","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"move cfg registration oop","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/4194cdbc96fcd8bd2cbe234f472b6ae6e9eb3bc2"},{"sha":"f802e4c25d297b27470d1423436715f02bac25d1","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"[MERGE #1683 @MikeHolman] fix oop jit issue with undefined const this\n\nMerge pull request #1683 from MikeHolman:inlinethis","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/f802e4c25d297b27470d1423436715f02bac25d1"},{"sha":"e817def1bc0449c0fbc61141ef775360b7f1476a","author":{"name":"Curtis Man","email":"b66d3d61317868ccbf53a8cae0740d6b09f42b49@microsoft.com"},"message":"Optimizing ForInObjectEnumerator overhead\n\nThe overhead for ForInObjectEnumerator can become significant if we enumerate a lot of object with small number of properties.\n\nThis change improves Sunspider by about 3.5ms (or 1.6%) and Speedometer by about 60ms (or 0.6%) on my machine.\nNo change on Octane or Kraken.\n\n1.  Allocate ForInObjectEnumerator on the stack instead of dynamically\n- Keep track of the maximum for..in loop depth at byte code generation.\n- Change the for..in byte code to InitForInEnumerator and BrOnEmpty to refer to the for..in loop depth\n- Allocate stack space for the ForInObjectEnumerator for interpreter and JIT'ed code.\n- When bailing out of JIT'ed code, the bailout interpreter frame will not allocate new stack space for the ForInObjectEnumerator, but instead reuse the space allocated on the JIT'ed frame.\n- When we are in JIT loop body, it also won't allocate new ForInObjectEnumerator. the loop body code will instead refer to the ForInObjectEnumerator allocated in the interpreter frame.\n- In JIT inlining, we need to keep track of inlinee for..in loop depth as well to allocate enough space for all of them.\n\n2. Reduce the size of ForInObjectEnumerator\n- Remove scriptContext and flags fields in ForInObjectEnumerator by reusing the same fields in DynamicObjectPropertyEnumerator and always initializing those.\n- Move all the fields needed to keep track of properties shadowing in prototypes into a dynamically allocated structure.  We already needed to allocate the sparse bit vector before already, so this is not a new allocation, but it will minimize stack usage for cases that doesn't have enumerable properties on the prototype.\n\n3. Add inline cache that maps the object type to DynamicObjectPropertyEnumerator::CacheData on InitForInEnumerator\n- The cache is pass to all GetEnumerator API to be given to DynamicObjectPropertyEnumerator to avoid the dictionary look up\n- Since we clear the type to cache data map on every GC, we also clear the inline cache on every GC as well.\n\n4. Implemented JIT fast path for OP_InitForInEnumerator and improved JIT fast path for BrOnEmpty\n- Implemented the OP_InitForInEnumerator when we have an inline cache match, with a plain dynamic object, doesn't have enumerable property on the prototype and doesn't index properties (object array)\n- Instead of checking multiple conditions, initialize a single bool on ForInObjectEnumerator canUseJITFastPath to indicate whether we can use the fast path, that combines the check for no prefix/array enumerator, no enumerable property on the prototype and have cache data\n- Avoid going to the helper before we exit the loop by adding a loop exit check for whether the cache is complete at the end of the enumeration\n- If prototype doesn't have any enumerable property, we don't have to keep track of shadowing.  So just ask the object enumerator to return enumerable property only, so that the for in object enumerator and the jit fast path doesn't have to check whether the property is enumerable or not.\n\n5. Minor cleanup\n- Delete JavascriptEnumeratorIterator, which is no longer used.\n- Refactor code in the backend to add loop in lower","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/e817def1bc0449c0fbc61141ef775360b7f1476a"},{"sha":"ca71469112b6b336307aa1ed2cf9e386df96c005","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"[MERGE #1686 @MikeHolman] require min of VS2015 Update 3 for constexpr\n\nMerge pull request #1686 from MikeHolman:vsconstexpr","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/ca71469112b6b336307aa1ed2cf9e386df96c005"},{"sha":"dff756b33231a67a0be18d7e9ffeebeaf1e4905c","author":{"name":"Curtis Man","email":"b66d3d61317868ccbf53a8cae0740d6b09f42b49@microsoft.com"},"message":"[MERGE #1641 @curtisman] Optimizating ForInObjectEnumerator overhead\n\nMerge pull request #1641 from curtisman:forin\n\nThe overhead for ForInObjectEnumerator can become significant if we enumerate a lot of object with small number of properties.\n\nThis change improves Sunspider by about 3.5ms (or 1.6%) and Speedometer by about 60ms (or 0.6%) on my machine.\nNo change on Octane or Kraken.\n\n1.  Allocate ForInObjectEnumerator on the stack instead of dynamically\n  - Keep track of the maximum for..in loop depth at byte code generation.\n  - Change the for..in byte code to InitForInEnumerator and BrOnEmpty to refer to the for..in loop depth\n  - Allocate stack space for the ForInObjectEnumerator for interpreter and JIT'ed code.\n  - When bailing out of JIT'ed code, the bailout interpreter frame will not allocate new stack space for the ForInObjectEnumerator, but instead reuse the space allocated on the JIT'ed frame.\n  - When we are in JIT loop body, it also won't allocate new ForInObjectEnumerator. the loop body code will instead refer to the ForInObjectEnumerator allocated in the interpreter frame.\n  - In JIT inlining, we need to keep track of inlinee for..in loop depth as well to allocate enough space for all of them.\n\n2. Reduce the size of ForInObjectEnumerator\n  - Remove scriptContext and flags fields in ForInObjectEnumerator by reusing the same fields in DynamicObjectPropertyEnumerator and always initializing those.\n  - Move all the fields needed to keep track of properties shadowing in prototypes into a dynamically allocated structure.  We already needed to allocate the sparse bit vector before already, so this is not a new allocation, but it will minimize stack usage for cases that doesn't have enumerable properties on the prototype.\n\n3. Add inline cache that maps the object type to DynamicObjectPropertyEnumerator::CacheData on InitForInEnumerator\n  - The cache is pass to all GetEnumerator API to be given to DynamicObjectPropertyEnumerator to avoid the dictionary look up\n  - Since we clear the type to cache data map on every GC, we also clear the inline cache on every GC as well.\n\n4. Implemented JIT fast path for OP_InitForInEnumerator and improved JIT fast path for BrOnEmpty\n  - Implemented the OP_InitForInEnumerator when we have an inline cache match, with a plain dynamic object, doesn't have enumerable property on the prototype and doesn't index properties (object array)\n  - Instead of checking multiple conditions, initialize a single bool on ForInObjectEnumerator canUseJITFastPath to indicate whether we can use the fast path, that combines the check for no prefix/array enumerator, no enumerable property on the prototype and have cache data\n  - Avoid going to the helper before we exit the loop by adding a loop exit check for whether the cache is complete at the end of the enumeration\n  - If prototype doesn't have any enumerable property, we don't have to keep track of shadowing.  So just ask the object enumerator to return enumerable property only, so that the for in object enumerator and the jit fast path doesn't have to check whether the property is enumerable or not.\n\n5. Minor cleanup\n  - Delete JavascriptEnumeratorIterator, which is no longer used.\n  - Refactor code in the backend to add loop in lower","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/dff756b33231a67a0be18d7e9ffeebeaf1e4905c"},{"sha":"c7884513ad9dfe1c2fc19de1fb338ef944da8680","author":{"name":"Michael Holman","email":"9a64a5f12fd4f8914cfc0bb37ae232ef80a40ef5@microsoft.com"},"message":"[MERGE #1607 @MikeHolman] move cfg registration oop\n\nMerge pull request #1607 from MikeHolman:cfgoop\n\nmoves cfg registration to server side","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/c7884513ad9dfe1c2fc19de1fb338ef944da8680"},{"sha":"8c4015ff916a5d1ba1cfd9acece21960574ed8ce","author":{"name":"Sandeep Agarwal","email":"5e14cd45ea7d426e2b28c1583d389e139e95a17a@microsoft.com"},"message":"Set debugContext to null before calling close and HeapDelete\n\nIn multiple context scenarios (Slate) with chk builds I see debugContext\nis not null and is garbage, ScriptContext is in closed state which means\ndebugContext is in the process of being deleted and has not be set to null.\nI can put critical section to the particular AV but it’s better to hold\ndebugContext in a temporary variable set scriptContext->debugContext to\nnull and then HeapDelete memory pointed by temporary variable.\n\nI have kept the autoDebugContextCloseCS for PDM case though it should\nnot be needed (I think so)","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/8c4015ff916a5d1ba1cfd9acece21960574ed8ce"},{"sha":"54ed1e616dc4143ee8387d238c531c14e6501294","author":{"name":"Sandeep Agarwal","email":"5e14cd45ea7d426e2b28c1583d389e139e95a17a@microsoft.com"},"message":"[MERGE #1695 @agarwal-sandeep] Set debugContext to null before calling close and HeapDelete\n\nMerge pull request #1695 from agarwal-sandeep:debugcontextdelete\n\nIn multiple context scenarios (Slate) with chk builds I see debugContext\nis not null and is garbage, ScriptContext is in closed state which means\ndebugContext is in the process of being deleted and has not be set to null.\nI can put critical section to the particular AV but it’s better to hold\ndebugContext in a temporary variable set scriptContext->debugContext to\nnull and then HeapDelete memory pointed by temporary variable.\n\nI have kept the autoDebugContextCloseCS for PDM case though it should\nnot be needed (I think so)","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/54ed1e616dc4143ee8387d238c531c14e6501294"},{"sha":"e8b715d37227834f404e7c6caecfdbe694559280","author":{"name":"Derek Morris","email":"5648f3b6467e6f880d869a7774634af53b826b8c@microsoft.com"},"message":"If we have no user crash handler we should generate additional info.\n\nThe previous way we were doing things, we'd only generate the additional\nbacktrace information about arguments and the like when an exception was\n_totally_ uncaught. This interfered with our implicit autocatchhandlers,\nwhich were added for some instructions. This caused divergences with the\nnonative version of the debug output, where we wouldn't add these, which\ncaused us to only generate the additional backtrace information in a few\nof the test configurations, but not all of them. By allowing creation of\nthe additional backtrace information when we have a catch handler but no\nuser catch handler, we handle these cases more uniformly.\n\nThis does, however, mean that our information on whether or not there is\na user catch handler; the existing code does this to some degree, but it\nis polluted by a bunch of implied catch handlers in both interpreter and\nin helper code. I added an argument to autocatchhandler to specify if we\ncan mark a particular instance of the autocatchhandler as user-made; the\nvalues that I've chosen for it (i.e. where it is true) should be checked\nand verified. Note that if the argument is true, that only means that it\n_can_ be a user catch handler; if it's not in user code (e.g. in chakra-\ngenerated JS) then it still won't be marked as a user catch handler.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/e8b715d37227834f404e7c6caecfdbe694559280"},{"sha":"cbef9d84c5751f61c5d264169062e9b353ef5016","author":{"name":"Derek Morris","email":"5648f3b6467e6f880d869a7774634af53b826b8c@microsoft.com"},"message":"Add test, fix nits.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/cbef9d84c5751f61c5d264169062e9b353ef5016"},{"sha":"29d4f52fa54e4234862f615b80c1cdd1014530a0","author":{"name":"Curtis Man","email":"b66d3d61317868ccbf53a8cae0740d6b09f42b49@microsoft.com"},"message":"FindNextProperty needs to return string in the request context, not of it's own context.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/29d4f52fa54e4234862f615b80c1cdd1014530a0"},{"sha":"02df0a02e2e2d7a701581ce8829ce9abc016c102","author":{"name":"Derek Morris","email":"5648f3b6467e6f880d869a7774634af53b826b8c@microsoft.com"},"message":"[MERGE #1681 @Penguinwizzard] If we have no user crash handler we should generate additional info.\n\nMerge pull request #1681 from Penguinwizzard:bug9006509\n\nThe previous way we were doing things, we'd only generate the additional\nbacktrace information about arguments and the like when an exception was\n_totally_ uncaught. This interfered with our implicit autocatchhandlers,\nwhich were added for some instructions. This caused divergences with the\nnonative version of the debug output, where we wouldn't add these, which\ncaused us to only generate the additional backtrace information in a few\nof the test configurations, but not all of them. By allowing creation of\nthe additional backtrace information when we have a catch handler but no\nuser catch handler, we handle these cases more uniformly.\n\nThis does, however, mean that our information on whether or not there is\na user catch handler; the existing code does this to some degree, but it\nis polluted by a bunch of implied catch handlers in both interpreter and\nin helper code. I added an argument to autocatchhandler to specify if we\ncan mark a particular instance of the autocatchhandler as user-made; the\nvalues that I've chosen for it (i.e. where it is true) should be checked\nand verified. Note that if the argument is true, that only means that it\n_can_ be a user catch handler; if it's not in user code (e.g. in chakra-\ngenerated JS) then it still won't be marked as a user catch handler.","distinct":false,"url":"https://api.github.com/repos/Microsoft/ChakraCore/commits/02df0a02e2e2d7a701581ce8829ce9abc016c102"}]}
{"actor":{"display_login":"chakrabot"}}