Merge Master to Linux #1430
Merged
Merge Master to Linux #1430
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tion's enclosing scope be represented as an object. We were missing a case where the function is located in a param scope that will later be merge with a body scope. Also adding asserts to verify the object-ness of a scope when we're generating byte code that requires it.
…ctions containing 'with' Merge pull request chakra-core#1388 from pleath:with Call to a nested function from within a 'with' requires that the function's enclosing scope be represented as an object. We were missing a case where the function is located in a param scope that will later be merge with a body scope. Also adding asserts to verify the object-ness of a scope when we're generating byte code that requires it.
Merge pull request chakra-core#1392 from digitalinfinity:linux
Merge pull request chakra-core#1383 from tcare:tostringtag - Enabled @@toStringTag by default. Updated baselines. - Removed the legacy helpers. We only have one special case now; any external object that would have resulted in [object Object] under new rules reverts back to the class name. This retains compat with both DOM and WinRT. - Fixed the coverage for proxy which was outdated. - Fixed OS 8331493, a nightly test that was failing.
…ent with JIT code
It is only available in VC compiler
…or linux build Merge pull request chakra-core#1394 from curtisman:fix It is only available in VC compiler
The JavascriptEnumerator function GetCurrentAndMoveNext is misleading because. Because it move to the next one before return the next element that we moved to. Change to MoveAndGetNext. Also remove MoveNext/GetCurrentIndex/GetCurrentPropertyId, which is equivalent to GetCurrentAndMoveNext. Move all usage of those API to MoveAndGetNext.
Fix some special cases of 'new.target' reference, e.g.: - 'new.target' inside direct eval() in global function throws SyntaxError - 'new.target' inside indirect eval() throws SyntaxError - 'new.target' inside function evaluates to undefined for function call - 'new.target' inside function evaluates to said function for constructor call - lambda+eval in global function called in a function (SyntaxError) - lambda+eval in a function called by global function (okay) - other nested/compounded cases with eval(), arrow functions, and functions
Merge pull request chakra-core#1377 from suwc:build/suwc/buddy Fix some special cases of 'new.target' reference, e.g.: - 'new.target' inside direct eval() in global function throws SyntaxError - 'new.target' inside indirect eval() throws SyntaxError - 'new.target' inside function evaluates to undefined for function call - 'new.target' inside function evaluates to said function for constructor call - lambda+eval in global function called in a function (SyntaxError) - lambda+eval in a function called by global function (okay) - other nested/compounded cases with eval(), arrow functions, and functions
…rface Merge pull request chakra-core#1400 from curtisman:enumclean The JavascriptEnumerator function GetCurrentAndMoveNext is misleading because. Because it move to the next one before return the next element that we moved to. Change to MoveAndGetNext. Also remove MoveNext/GetCurrentIndex/GetCurrentPropertyId, which is equivalent to GetCurrentAndMoveNext. Move all usage of those API to MoveAndGetNext.
Add support for module namespace. The basic syntax is export * as myNS from 'submodule.js' The namespace is a sealed object with all the exported properties from the currently module. The properties are not changable. They are also "reference property" in that it should look up the original property instead of caching the value of the property. There are three set of properties in the namespace object: . builtin Symbol properties, include Symbol.toStringTag & Symbol.iterator at this time. . local exports. As the local exports are allocated in the specific slot array. . nonlocal exports. We need to forward the call to other referencing module namespace object. Similarly, the enumerator needs to take care of the different kinds of properties. However, the iterator need to iterate through the property names in sorted order. We'll create the iterator for a sorted name list. CreateListIterator operation (7.4.8) is implemented as well. Add a set of unittests to cover the object behavior of namespace object.
…ake its SListBase members to be exception safe Merge pull request chakra-core#1395 from ThomsonTan:FixCapturedValuesException CapturedValues with 2 members of SListBase is used as stack variable in GlobOpt. The dtor of SListBase will complain if exception happened before destructing CapturedValues. This fix added dtor to CapturedValues to Reset 2 SListBase member before destruct them.
…nterpreter to make the result consistent with JIT code Merge pull request chakra-core#1396 from ThomsonTan:FixMathPowInconsistency Interpreter always go to slow path of Math.pow because the perf win is not substantial in interpreter, and but could give more accurate float point result. This leads to result inconsistency between JIT code and interpreter. This fix checks fast path in interpreter to make the result consistent.
…uild status table. Merge pull request chakra-core#1403 from dilijev:readme
…because of inconsistent finalization flags state. Reviewed by @Yongqu
…causing many hits on the OOM path because of inconsistent finalization flags state. Merge pull request chakra-core#1362 from dilijev:finalized Reviewed by @Yongqu
Merge pull request chakra-core#1404 from digitalinfinity:warning_fix Disable a warning in VS2013 in Utf8Codex.cpp (it's disabled through the rest of the project anyway, but Codex doesn't use the header that disables those warnings so explicitly disable for Utf8Codex too)
Merge pull request chakra-core#1405 from dilijev:readme
…ferences
When we do BindPidRefsInScope, we walk the PidRef stack and check to see
if any ref is non-local. Global and module export symbols should never be
marked as non-local.
Problem is that not all refs in the PidRef stack are necessarily marked to
indicate that the symbol is a module export. If a symbol which is an
export has a non-local ref which does not indicate it is a module export,
we will erroneously set the hasNonLocalReference flag on that symbol.
Here's an example of how this can happen:
function foo() { };
export { foo };
In this case, the top ref to symbol foo does not say that foo is a module
export so we might set the hasNonLocalReference flag on symbol foo when we
look at the top ref. The next ref in the PidRef stack would indicate that
foo is a symbol but by then we've already marked it.
A fix is to move the module export flag out of PidRef and into the Ident
itself. Then we can check to see if the pid is a module export before we
walk the PidRef stack in BindPidRefsInScope.
…not be marked as having non-local references Merge pull request chakra-core#1384 from boingoing:moduleexporthasnonlocalreference When we do BindPidRefsInScope, we walk the PidRef stack and check to see if any ref is non-local. Global and module export symbols should never be marked as non-local. Problem is that not all refs in the PidRef stack are necessarily marked to indicate that the symbol is a module export. If a symbol which is an export has a non-local ref which does not indicate it is a module export, we will erroneously set the hasNonLocalReference flag on that symbol. Here's an example of how this can happen: function foo() { }; export { foo }; In this case, the top ref to symbol foo does not say that foo is a module export so we might set the hasNonLocalReference flag on symbol foo when we look at the top ref. The next ref in the PidRef stack would indicate that foo is a symbol but by then we've already marked it. A fix is to move the module export flag out of PidRef and into the Ident itself. Then we can check to see if the pid is a module export before we walk the PidRef stack in BindPidRefsInScope.
…ination operand is same as both source operands Merge pull request chakra-core#1411 from meg-gupta:fixarmstrictneq When destination of CmpSrNeq_A is same as both its sources, we need to generate instructions that saves the value of both the sources in newly created Opnds. Current codegen did not check the case when destination can be equal to both the sources. This change fixes it.
Merge pull request chakra-core#1401 from Yongqu:modulens Add support for module namespace. The basic syntax is export * as myNS from 'submodule.js' The namespace is a sealed object with all the exported properties from the currently module. The properties are not changable. They are also "reference property" in that it should look up the original property instead of caching the value of the property. There are three set of properties in the namespace object: . builtin Symbol properties, include Symbol.toStringTag & Symbol.iterator at this time. . local exports. As the local exports are allocated in the specific slot array. . nonlocal exports. We need to forward the call to other referencing module namespace object. Similarly, the enumerator needs to take care of the different kinds of properties. However, the iterator need to iterate through the property names in sorted order. We'll create the iterator for a sorted name list. CreateListIterator operation (7.4.8) is implemented as well. Add a set of unittests to cover the object behavior of namespace object.
`CheckIfTypeIsEquivalent` helper is called from JITted code to perform equivalent type check. It validates if the object's type is present in one of the 8 cached equivalent types and if yes, updates the guard value and return back to JITted code. If not, it takes slow path and verifies the prototype of object to that of cached type. However if guard is not valid, we would just bailout `BailOutFailedEquivalentTypeCheck`. Today in `PreSweepCallback` we would invalidate the guard if the underline type is not marked. However we could have invalid guard value but if there are alive types present in equivTypes[], we could use them to check if `type` in question matches any of them and if yes, update the guard value, so next time JIT code will be able to take advantage of it next time. On instrumenting code, noticed that there are high frequency that this happens (at least in acmeair) where we have valid equivTypes[], but we don'take take its advantage just because guard value is invalid. This gives approx. 2.5 % win in acmeair. Other benchmarks are flat. Also, I noticed that the cache eviction policy was kicking out valid caches despite of having empty slots in types[] where new type could have been stored. Modified the eviction logic to take advantage of empty slots before going to existing eviction logic. I have also added logic to compact the equivTypes by moving non-null types towards front of array. Test: Internal tools pass Perf: Standard benchmarks are almost flat with minor improvement in Octane, Kraken. Acme-air shows 2.5% win.
Merge pull request chakra-core#1368 from kunalspathak:typecheck `CheckIfTypeIsEquivalent` helper is called from JITted code to perform equivalent type check. It validates if the object's type is present in one of the 8 cached equivalent types and if yes, updates the guard value and return back to JITted code. If not, it takes slow path and verifies the prototype of object to that of cached type. However if guard is not valid, we would just bailout `BailOutFailedEquivalentTypeCheck`. Today in `PreSweepCallback` we would invalidate the guard if the underline type is not marked. However we could have invalid guard value but if there are alive types present in equivTypes[], we could use them to check if `type` in question matches any of them and if yes, update the guard value, so next time JIT code will be able to take advantage of it next time. On instrumenting code, noticed that there are high frequency that this happens (at least in acmeair) where we have valid equivTypes[], but we don'take take its advantage just because guard value is invalid. This gives approx. 2.5 % win in acmeair. Other benchmarks are flat. Also, I noticed that the cache eviction policy was kicking out valid caches despite of having empty slots in types[] where new type could have been stored. Modified the eviction logic to take advantage of empty slots before going to existing eviction logic. I have also added logic to compact the equivTypes by moving non-null types towards front of array. Test: Internal tools pass Perf: Standard benchmarks are almost flat with minor improvement in Octane, Kraken. Acme-air shows 2.5% win.
function(){...}', 'o[s] = function(){...}', or 'return f(){...}'. Doing so at parse time allows us to disable stack-nested-functions in common cases where an escape is not detected at byte code gen time because of deferred parsing.
…un longer on busy or low-resource test VMs. We've observed them run for around 120 seconds; increasing the timeout to 300 seconds (5 minutes) should more than account for this. Fixes chakra-core#1406 and chakra-core#1417
…tection Merge pull request chakra-core#1416 from pleath:8090616 Allow the parser to detect nested function escapes of the pattern 'o.f = function(){...}' or 'o[s] = function(){...}'. Doing so at parse time allows us to disable stack-nested-functions in common cases where an escape is not detected at byte code gen time because of deferred parsing.
….js and array_slice.js which can run longer on busy or low-resource test VMs. Merge pull request chakra-core#1421 from dilijev:timeout We've observed them run for around 120 seconds; increasing the timeout to 300 seconds (5 minutes) should more than account for this. Fixes chakra-core#1406 Fixes chakra-core#1417
…a byte level memset. This was valid ints but not for floats. Changed the check to really see if the bytes are all the same
…oat array with -1 Merge pull request chakra-core#1361 from Cellule:memop_setsamebytes We used to check if the memset value is -1 to determine if we can do a byte level memset. This was valid ints but not for floats. Changed the check to really see if the bytes are all the same.
chakrabot
pushed a commit
that referenced
this pull request
Aug 13, 2016
Merge pull request #1430 from obastemur:m_merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.