forked from chakra-core/ChakraCore
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add additional ETW instrumentation #1
Open
digitalinfinity
wants to merge
7,438
commits into
master
Choose a base branch
from
pr/digitalinfinity/ch_etw_enh
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
This change puts a polymorphic inline cache on JavascriptSymbol so that it can act like PropertyString and cache information about loads and stores that use it. It also adds a cache mapping property IDs to JavascriptSymbol weak refs in ScriptContext, similar to the existing cache for PropertyStrings, and modifies existing code to not create new JavascriptSymbol instances unless necessary. When lowering a load or store with a likely symbol, we can emit code that is very similar to the fast path for strings.
…g Symbols Merge pull request chakra-core#4569 from sethbrenith:user/sethb/cache-symbol-ops This change puts a polymorphic inline cache on JavascriptSymbol so that it can act like PropertyString and cache information about loads and stores that use it. It also adds a cache mapping property IDs to JavascriptSymbol weak refs in ScriptContext, similar to the existing cache for PropertyStrings, and modifies existing code to not create new JavascriptSymbol instances unless necessary. When lowering a load or store with a likely symbol, we can emit code that is very similar to the fast path for strings.
Failing builtin init should be fail fast pass stackoverflow exception above
… to not read root property Merge pull request chakra-core#4589 from meg-gupta:addCheckOnRootPropLd Also add assert so that in future we dont write js builtin code to access any root property Fixes OS#15467762
…ation code to not read root property Merge pull request chakra-core#4589 from meg-gupta:addCheckOnRootPropLd Also add assert so that in future we dont write js builtin code to access any root property Fixes OS#15467762
…tIn initialization code to not read root property Merge pull request chakra-core#4589 from meg-gupta:addCheckOnRootPropLd Also add assert so that in future we dont write js builtin code to access any root property Fixes OS#15467762
When the JsObject* functions were added to JSRT there was an attempt to refactor the TTD instrumentation into a common method. The refactor caused a regression in cross-context scenarios where the record was capturing both the result of the function as well as any marshalling necessary to get the result. This change reverts the behavior of the existing methods (e.g. JsSetProperty and friends) to capture the record before any marshalling can occur (VALIDATE_INCOMING_OBJECT will marshal the object if necessary). For the new JsObject* functions I've added an assert to ensure that once they are used they will cause TTD record to fail with an actionable message.
Recent OSX distros have clock_gettime support. Use it when it's available (~3 times faster to what we do to replace that)
…ct* function refactor Merge pull request chakra-core#4591 from kfarnung:ttdobjects When the JsObject* functions were added to JSRT there was an attempt to refactor the TTD instrumentation into a common method. The refactor caused a regression in cross-context scenarios where the record was capturing both the result of the function as well as any marshalling necessary to get the result. This change reverts the behavior of the existing methods (e.g. JsSetProperty and friends) to capture the record before any marshalling can occur (VALIDATE_INCOMING_OBJECT will marshal the object if necessary). For the new JsObject* functions I've added an assert to ensure that once they are used they will cause TTD record to fail with an actionable message.
JsConvertValueToString can implicitly marshal values between script contexts. Even if there's no conversion occurring the result still needs to be recorded.
…s from JsObject* function refactor Merge pull request chakra-core#4591 from kfarnung:ttdobjects When the JsObject* functions were added to JSRT there was an attempt to refactor the TTD instrumentation into a common method. The refactor caused a regression in cross-context scenarios where the record was capturing both the result of the function as well as any marshalling necessary to get the result. This change reverts the behavior of the existing methods (e.g. JsSetProperty and friends) to capture the record before any marshalling can occur (VALIDATE_INCOMING_OBJECT will marshal the object if necessary). For the new JsObject* functions I've added an assert to ensure that once they are used they will cause TTD record to fail with an actionable message.
…JsCreate*Function changes Merge pull request chakra-core#4590 from kfarnung:ttdfunction
…match recent JsCreate*Function changes Merge pull request chakra-core#4590 from kfarnung:ttdfunction
…ueToString fast path Merge pull request chakra-core#4592 from kfarnung:ttdstrings JsConvertValueToString can implicitly marshal values between script contexts. Even if there's no conversion occurring the result still needs to be recorded.
… JsConvertValueToString fast path Merge pull request chakra-core#4592 from kfarnung:ttdstrings JsConvertValueToString can implicitly marshal values between script contexts. Even if there's no conversion occurring the result still needs to be recorded.
…ast fromIndex discovery Merge pull request chakra-core#4588 from obastemur:faster_bvsparse Helps the number of tests not to timeout on CI machines.
…available Merge pull request chakra-core#4593 from obastemur:use_clock_gettime_osx Recent OSX distros have clock_gettime support. Use it when it's available (~3 times faster to what we do to replace that)
…o preserve the record life time Merge pull request chakra-core#4580 from obastemur:props_swb
…und' for fast fromIndex discovery Merge pull request chakra-core#4588 from obastemur:faster_bvsparse Helps the number of tests not to timeout on CI machines.
…keep 'last found' for fast fromIndex discovery Merge pull request chakra-core#4588 from obastemur:faster_bvsparse Helps the number of tests not to timeout on CI machines.
…when it's available Merge pull request chakra-core#4593 from obastemur:use_clock_gettime_osx Recent OSX distros have clock_gettime support. Use it when it's available (~3 times faster to what we do to replace that)
…lock_gettime when it's available Merge pull request chakra-core#4593 from obastemur:use_clock_gettime_osx Recent OSX distros have clock_gettime support. Use it when it's available (~3 times faster to what we do to replace that)
…nterface to preserve the record life time Merge pull request chakra-core#4580 from obastemur:props_swb
…pertyRecord interface to preserve the record life time Merge pull request chakra-core#4580 from obastemur:props_swb
Merge pull request chakra-core#4595 from obastemur:fix_19_build
Merge pull request chakra-core#4595 from obastemur:fix_19_build
…reaks. Merge pull request chakra-core#4659 from MSLaguana:fixTTD Some node-chakracore tests were throwing asserts when run with TTD.
…lined across source files Merge pull request chakra-core#4609 from sethbrenith:user/sethb/inline-getters This change allows a cross-script getter call both to be flagged as an inline candidate from `DynamicProfileInfo::RecordLdFldCallSiteInfo` and to be selected for inlining in `NativeCodeGenerator::GatherCodeGenData`. It also updates a few places to treat public library code like JS built-in code, since public library code uses `noContextSourceContextInfo` and therefore doesn't contain call-site info. This came up in some tests that were calling public library code such as the getter for `Collator.compare`, which was then attempting to recursively inline.
…or missing values even if not in head segment Merge pull request chakra-core#4650 from MikeHolman:missingmemop This may cause us to incorrectly set `HasNoMissingValues(false);` OS: 15399206
…e binding incorrectly marked as module export storage Merge pull request chakra-core#4662 from tcare:classexport We were mistakenly marking both the class let and const decls as module export storage. This resulted in empty instantiated scopes and incorrect class behavior in some cases. The fix is not to mark the const binding as module export storage, as it is visible to the inside of the class only. Added some tests to verify the bindings of exported classes.
…may scan for missing values even if not in head segment Merge pull request chakra-core#4650 from MikeHolman:missingmemop This may cause us to incorrectly set `HasNoMissingValues(false);` OS: 15399206
… where memop may scan for missing values even if not in head segment Merge pull request chakra-core#4650 from MikeHolman:missingmemop This may cause us to incorrectly set `HasNoMissingValues(false);` OS: 15399206
… const name binding incorrectly marked as module export storage Merge pull request chakra-core#4662 from tcare:classexport We were mistakenly marking both the class let and const decls as module export storage. This resulted in empty instantiated scopes and incorrect class behavior in some cases. The fix is not to mark the const binding as module export storage, as it is visible to the inside of the class only. Added some tests to verify the bindings of exported classes.
…e#2949: Class const name binding incorrectly marked as module export storage Merge pull request chakra-core#4662 from tcare:classexport We were mistakenly marking both the class let and const decls as module export storage. This resulted in empty instantiated scopes and incorrect class behavior in some cases. The fix is not to mark the const binding as module export storage, as it is visible to the inside of the class only. Added some tests to verify the bindings of exported classes.
…d xplat tests Merge pull request chakra-core#4656 from obastemur:enable_other_xplat_tests Fixes chakra-core#3012 Fixes chakra-core#2064
…st for OSX Merge pull request chakra-core#4653 from obastemur:enable_math_Builtins_osx Fixes chakra-core#4537
…nable disabled xplat tests Merge pull request chakra-core#4656 from obastemur:enable_other_xplat_tests Fixes chakra-core#3012 Fixes chakra-core#2064
…insCall test for OSX Merge pull request chakra-core#4653 from obastemur:enable_math_Builtins_osx Fixes chakra-core#4537
…ble MathBuiltinsCall test for OSX Merge pull request chakra-core#4653 from obastemur:enable_math_Builtins_osx Fixes chakra-core#4537
clear the function table for loop body entrypoing case when debugger attaching, this is done for function entrypoint in last change but missed loop body case. also make sure of the integrity of clearing function table in the slist.
…eds further investigation.
…ker fix Merge pull request chakra-core#4667 from pleath:15176668
… stack walker fix Merge pull request chakra-core#4667 from pleath:15176668
…: Port remote stack walker fix Merge pull request chakra-core#4667 from pleath:15176668
…/detaching case as well
…g for loop body cleanup Merge pull request chakra-core#4666 from leirocks:xdata1 clear the function table for loop body entrypoint case. when debugger attaching the code address is not freed through normal path hence clearing the xdata in main thread. this is done for function entrypoint in last change but missed loop body case. also make sure of the integrity of clearing function table in the slist.
…le clearing for loop body cleanup Merge pull request chakra-core#4666 from leirocks:xdata1 clear the function table for loop body entrypoint case. when debugger attaching the code address is not freed through normal path hence clearing the xdata in main thread. this is done for function entrypoint in last change but missed loop body case. also make sure of the integrity of clearing function table in the slist.
…g core unit test toUint16.js DRT. Needs further investigation. Merge pull request chakra-core#4665 from atulkatti:DRT.Fixes.1
… function table clearing for loop body cleanup Merge pull request chakra-core#4666 from leirocks:xdata1 clear the function table for loop body entrypoint case. when debugger attaching the code address is not freed through normal path hence clearing the xdata in main thread. this is done for function entrypoint in last change but missed loop body case. also make sure of the integrity of clearing function table in the slist.
…led failing core unit test toUint16.js DRT. Needs further investigation. Merge pull request chakra-core#4665 from atulkatti:DRT.Fixes.1
…3 [RS4] Disabled failing core unit test toUint16.js DRT. Needs further investigation. Merge pull request chakra-core#4665 from atulkatti:DRT.Fixes.1
…(). Fixes chakra-core#4663 Merge pull request chakra-core#4670 from sethbrenith:user/sethb/super-return Return correct value from super(). Fixes chakra-core#4663
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.