Simd.js library support #3
Closed
Conversation
This file contains 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
|
Hi @arunetm, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! The agreement was validated by Microsoft and real humans are currently evaluating your PR. TTYL, MSBOT; |
|
@LouisLaf @abchatra @nmostafa @litian2025 Please review this change. |
|
|
@dotnet-bot test this please |
|
Replaced by #106 |
Merged
chakrabot
pushed a commit
that referenced
this pull request
Feb 12, 2016
Merge pull request #305 from pleath:released/1602 #1: Fix bugs with non-canonical NaNs in asm.js In asm.js, we don't canonicalize NaNs. We don't have vars in asm.js, so this is ok. But we DO need to make sure to check for NaN if we are creating a JavascriptNumber from it. However, we were not doing this, which was an issue for argouts in asm.js->js calls as well as return values from asm.js. It was also an issue in one helper call on x64, where we were converting to var before making the call. This was being done because there was no support for x64 calling convention. But with asm.js, I implemented that support, so I updated the helper call to use the standard API. Other places were also hacking around this limitation, so I updated them as well. #2: add check against length for memset #3: Issue: There was a code path where we protect pages with PAGE_EXECUTE without the PAGE_TARGETS_NO_UPDATE flag, which will control all the CFG bits in the page. Fix: Fixed and ensured that we don't use PAGE_EXECUTE directly in the virtual protect API. Instead #defines are used. Cleaned up some complex code path in CustomHeap Protect Allocation mechanism. Removed isReadWrite flag from PageAllocation class, as it is not required. Earlier, we were also letting RW pages to be added to the bucket list of pages in custom heap, which lead the hacker to add his own RW page to the list. Now it is made sure that only RX pages go into the bucket list. Tests: Unit tests passed. Exprgen, Web crawler - Reran the tests and they look fine..
chakrabot
pushed a commit
that referenced
this pull request
Mar 5, 2016
Merge pull request #432 from Yongqu:module Implement the remaining operations in SourceTextModuleRecord, including mainly ResolveExport and GetExportNames operations. Start implementation of ModuleNamespace. Implemented GetModuleNamespace. Detailed namespace implementation is not in yet. Filled in some holes in earlier implementation, like error handling for top level operations, notify the parent module if the current module failed in parse or ModuleDeclarationInitialization. Export method for bytecode generator to retrieve the localexport slot information. Fixed some potential memory leak by implementing the Finalize method for SourceTextModuleRecord. Temporary disable ModuleEvaluation for non-root modules, pending bytecode generator change.
nmostafa
added a commit
to nmostafa/ChakraCore
that referenced
this pull request
Mar 10, 2016
nmostafa
added a commit
to nmostafa/ChakraCore
that referenced
this pull request
Mar 11, 2016
kunalspathak
added a commit
to kunalspathak/ChakraCore
that referenced
this pull request
May 24, 2016
…Records
Repro:
```js
function ctor() {
this.p = null;
this.q = null;
this.r = null;
this.s = null;
this.t = null;
this.u = null;
this.v = null;
this.w = null;
this.x = null;
this.y = null;
this.z = null;
}
var superObj1 = { x: '1' };
var superObj2 = { blah: '1' };
function stress() {
var req = Object.create(superObj1);
var a = new ctor();
req.__proto__ = superObj2;
// throw away req, but cache still remains around on tc
}
function test(iter) {
for (var i = 0; i < 1000000; i++) {
stress();
}
}
test(0);
print('done, sleeping...');
while(1){} // Before fix, at this point ch shows 240MB memory usage. After the fix it comes down to 170MB
```
Cause :
1. Create an object `req` whose prototype has a property `x`.
2. Let's say we create another object from `ctor()`.
The ctor also has property `x` in addition to other properties.
3. When we change the prototype of `req`, we invalidate all the properties in it's prototype as well.
We also invalidate the propertyGuards of the properties of prototype. Since propertyGuards are stored
at `threadContext`, we don't care which type was the property was associated with. We simply search for
propertyGuardEntry corresponding to the propertyRecord of a property and invalidate the propertyGuard
i.e. ctor cache of a constructor. In this case, we invalidate the propertyGuard for property `x` which
was on prototype of `req`. However the propertyGuard of `x` corresponds to ctor cache for `ctor()` from
which we created another object.
4. Next time, when an object is created from `ctor()`, it sees that the ctor cache is invalid and it creates new ctor cache.
When creating new ctor cache, all the properties of `ctor()` are again registered in propertyGuard table for new ctor cache.
5. What is missing here is when invalidating the ctor cache in chakra-core#3 above, we should also walk through property guards table
of other properties and clear the invalidated property guard entry from the unique property guard table. Since these are
not removed today, the table keeps growing retaining property guard entries of invalidated ctor cache leading to memory leak.
Fix: While invalidating a unique property guard, walk through the guards of other properties and remove the entry of property guard
getting invalidated from their table.
Test: UnitTest, benchmarks and internal test tools pass.
kunalspathak
added a commit
to kunalspathak/ChakraCore
that referenced
this pull request
May 31, 2016
…Records
Repro:
```js
function ctor() {
this.p = null;
this.q = null;
this.r = null;
this.s = null;
this.t = null;
this.u = null;
this.v = null;
this.w = null;
this.x = null;
this.y = null;
this.z = null;
}
var superObj1 = { x: '1' };
var superObj2 = { blah: '1' };
function stress() {
var req = Object.create(superObj1);
var a = new ctor();
req.__proto__ = superObj2;
// throw away req, but cache still remains around on tc
}
function test(iter) {
for (var i = 0; i < 1000000; i++) {
stress();
}
}
test(0);
print('done, sleeping...');
while(1){} // Before fix, at this point ch shows 240MB memory usage. After the fix it comes down to 170MB
```
Cause :
1. Create an object `req` whose prototype has a property `x`.
2. Let's say we create another object from `ctor()`.
The ctor also has property `x` in addition to other properties.
3. When we change the prototype of `req`, we invalidate all the properties in it's prototype as well.
We also invalidate the propertyGuards of the properties of prototype. Since propertyGuards are stored
at `threadContext`, we don't care which type was the property was associated with. We simply search for
propertyGuardEntry corresponding to the propertyRecord of a property and invalidate the propertyGuard
i.e. ctor cache of a constructor. In this case, we invalidate the propertyGuard for property `x` which
was on prototype of `req`. However the propertyGuard of `x` corresponds to ctor cache for `ctor()` from
which we created another object.
4. Next time, when an object is created from `ctor()`, it sees that the ctor cache is invalid and it creates new ctor cache.
When creating new ctor cache, all the properties of `ctor()` are again registered in propertyGuard table for new ctor cache.
5. What is missing here is when invalidating the ctor cache in chakra-core#3 above, we should also walk through property guards table
of other properties and clear the invalidated property guard entry from the unique property guard table. Since these are
not removed today, the table keeps growing retaining property guard entries of invalidated ctor cache leading to memory leak.
Fix: Add heuristic to clear invalidated property guards for all propertyIds. Expose `ConstructorCacheInvalidationThreshold` to
control the heuristic. If no. of invalidation of property guards reach threshold specified, it will do exhaustive lookup
to scan invalidated property guards entry and will remove them from `uniqueGuards`
dictionary.
Test: UnitTest, ieperflab, benchmarks and internal test tools pass.
ghost
mentioned this pull request
This was referenced Dec 14, 2021
Closed
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.
Simd.js library support