Summary:
Implement the API for querying the properties of an object found in a
heap snapshot.
Now when you are debugging and take a heap snapshot, you can hover
over an object and inspect it!
Only works for subclasses of JSObject. Doesn't work for stuff like HiddenClass,
PropertyAccessor, native objects like WeakValueMap, etc. Those internal objects
display "Preview is not available" which matches what Chrome prints for its own
internal stuff.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D27834672
fbshipit-source-id: 607a8984b5a48b76c5ae57f9bd5bf53168f3ec3f
Summary:
In the Chrome inspector, add support for `HeapProfiler.startSampling`
and `HeapProfiler.stopSampling`. These two protocols turn the sampling
heap profiler on and off, and write the results on the socket.
Then Chrome's visualizer pieces the information together to produce a flame graph
of memory usage.
Added a unit test to make sure sampling can be turned on and off, and there are some
samples returned.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D26835148
fbshipit-source-id: d1be3cee791e42da5d9e117c3b8259b6622b98f4
Summary:
This diff allows specifying the preemptive compilation threshold via CompileFlags.
Users get a toggle in CLI and RuntimeConfig that allows choosing between 1. fully eager, 2. fully lazy, 3. use default thresholds ("smart"). The default is #3.
However, since we use `-O` by default, it overrides any lazy compilation when
using the `hermes` binary.
ChangeLog: [Internal] Inspector updated to use new RuntimeConfig laziness control
Reviewed By: tmikov
Differential Revision: D23356463
fbshipit-source-id: 508b7b2e6a218346c69acfec97e7891e388f0e9b
Summary:
Changelog: [Internal][Added] Support for toggling all breakpoints in Chrome debuggers
This implements the Debugger.setBreakpointsActive CDP message, allowing
users in Chrome to toggle all exceptions on and off.
As with V8/Chrome, setting a breakpoint will automatically re-activate
all breakpoints.
#utd-hermes-ignore-android
Reviewed By: avp
Differential Revision: D22825209
fbshipit-source-id: bda2cc59aba04443280bca46126c19bb0cdb58d7
Summary:
This call is used to continue execution when the app has just been
started in a "wait for debugger" mode. This is the only case
in which it has an effect.
Notably, it should do nothing in the following cases, which a layperson
may be tempted to classify as "WaitingForDebugger":
* The app was running detached and hit a 'debugger;' statement
* The app is paused because of a breakpoint or hitting the Pause button
* The app stopped on an instrumentation breakpoint, and expects
the debugger to collect data and potentially auto-resume.
Changelog: [Internal] Add Hermes support for Debugger.runIfWaitingForDebugger
Reviewed By: mhorowitz
Differential Revision: D21557446
fbshipit-source-id: 790cec7444ddc61908d2ef9d92e4649b535d678f
Summary:
This diff adds support for the "beforeScriptWithSourceMapExecution" instrumentation
breakpoint via "Debugger.setInstrumentationBreakpoint".
CDP describes it as a breakpoint, but we just set a flag in the inspector. A
fake breakpoint ID is synthesized for optional removal later.
Changelog: [Internal] Add Debugger.setInstrumentationBreakpoint to Hermes Inspector
Reviewed By: mhorowitz
Differential Revision: D21418218
fbshipit-source-id: 90fa49c0954980993815322d3a7effee416ed5db
Summary:
We are currently very strict about breakpoint location matching. This
diff allows some fuzz in the column, but not in the line.
Changelog: [Internal] Setting Hermes breakpoints no longer requires exact column match
Reviewed By: avp
Differential Revision: D21343198
fbshipit-source-id: a59786a9d63f9fe1ed576835ed660ba3343affe1
Summary:
This diff implements the instruction pointer save/restore trick Tzvetan came up with; allowing us to observe and modify the IP from outside the interpreter loop with negligible overhead.
From Tzvetan's internal post on the subject:
> [Today] the interpreter IP is just a local variable in the interpreter function, so there is no way to get to its value from outside the function. It lives in a register and we don't want to make it a Runtime field since the overhead [of accessing it via memory in the interpeter loop] would kill us.
> However, if you really think about it, it only lives in a register while the interpreter function is running. For the rest of the time, it is spilled by the C++ compiler onto the stack.
So, precisely when we need it, it is actually stored in memory. The only problem is, we don't know where! Admittedly, that is an annoying problem, but it feels like it should be solvable.
> What if, instead of relying on the compiler to spill the IP register, we manually spill it ourselves, to a known location? It works. Example: https://godbolt.org/z/ftSDnp
This diff implements this approach across the whole interpreter loop: whenever we call out of the loop we capture/publish the IP and restore it again immediately after the external call returns. This means we can now see the IP outside the interpret loop and even change it. This is effectively "for free" as the compiler now skips spilling/restoring the IP behind the scenes.
The immediate benefit of this is knowing the current IP allows us to have more accurate stack-traces during execution. In future this may enabled tricks like changing the IP before returning to the interpreter loop, allowing things outside the interpreter to affect program flow without adding logic to the interpreter loop.
Reviewed By: tmikov
Differential Revision: D20151091
fbshipit-source-id: 3814382639800208d8985a32ede31ba8f7ff7c80
Summary:
This adds support for 'returnByValue' in Runtime.evaluate invocations.
If the result of the evaluation can't be serialized to JSON, the results
are undefined.
ChangeLog: [Internal] - Hermes Inspector now supports 'returnByValue' in CDP Runtime.evaluate calls
[Facebook]
This is change was made to support debug completion in VSCode for ReactVR.
Reviewed By: ArchDev
Differential Revision: D19961115
fbshipit-source-id: d20af82b35d6bde88ab74b5c5a4c07415122c142
Summary:
Changelog: [Internal]
Before, we were relying on checking out the `devtools-protocol` Github repo at a specific commit and
making special changes to the JSON file.
In order to make it easier to update, use the officially published npm package.
I found the closest package version that was published, but it had two differences:
* `Runtime.getHeapUsage` was either missing (in earlier versions) or experimental (in later versions)
* `isDefault` and `isPageContext` were removed. I'm not sure what these were used for anyway, the comment leads me to believe they're probably not necessary anymore
There were some customizations made previously to annotate `recursive` on some properties. The npm package doesn't set these,
so I wrote some checks to add it back in if it can be detected. This was mostly to handle one special case: `Runtime.StackTrace`.
The workaround seems to be fine for that case.
Reviewed By: willholen
Differential Revision: D19386890
fbshipit-source-id: db0d85f6bc71cba77ee67d85efe2f38376d7cc87
Summary:
Our current lazy compilation parent scope issue caused us to only have a
single lexical scope, which was taken to be the global scope. This
effectively hid all local variables. Additionally, the variables were
not marked as enumerable, so Chrome didn't show them.
As further improvements, 'this' is now included, and we more correctly
tag parent scopes as closures.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D18671527
fbshipit-source-id: cbbf9fbd319e433b9f681bd23e4ad7b4bb4a3d74
Summary:
setBreakpoint differs from the existing setBreakpointByUrl in that you
can specify a scriptId directly. This was not really possible before
now, since scriptIds were mapped via filenames rather than to
RuntimeModules.
When (re)loading files with the same name, this call can be used to set
breakpoints in a specific one, rather than just the latest version.
Changelog: [Internal]
Reviewed By: bestander
Differential Revision: D18362054
fbshipit-source-id: 6ff1e736c79a4e75dc424316675d426ce9902f5f
Summary:
We were calling `sendErrorToClient` on error, but this function only
returns a closure that we threw away. Change to actually send an error
response.
Changelog: [Internal]
Reviewed By: bestander
Differential Revision: D18362055
fbshipit-source-id: 2ff1750ffd2c32a9291d3ed74fa0aaecd76c64c6
Summary:
Yesterday we shipped hermesengine.dev as part of the current 0.60 release. This PR brings those changes to master.
## Changelog
[General] [Added] - Added support for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/25613
Test Plan:
* CI is green both on GitHub and at FB
* Creating a new app from source can use Hermes on Android
Reviewed By: cpojer
Differential Revision: D16221777
Pulled By: willholen
fbshipit-source-id: aa6be10537863039cb666292465ba2e1d44b64ef
Riley Dulin
Will Holen
Jacob Bower
Marc Horowitz
Andres Suarez
cpojer