8ca93205cc
The ExternalPointerTags are assumed to be compile-time constants in most cases, so turning them into template parameters enforces that. As decisions such as whether to use the per-isolate or the shared external pointer table are encoded into the tag values, forcing those to be compile-time constants guarantees that the compiler will be able to inline the correct logic when accessing an external pointer. With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods which require the ExternalPointerTag to be a template parameter, and the ExternalPointerSlot class which takes the tag as an argument. The latter is for example used for snapshot deserialization and by the garbage collector (more generally, by the ObjectVisitor::VisitExternalPointer method), where the tag is not a compile-time constant. Finally, this CL also introduces a new ExternalPointerHandle type which represents the (opaque) on-heap representation of a reference to an entry in an ExternalPointerTable when sandboxing is enabled. Making this its own type makes the code a bit more readable. Bug: v8:10391 Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720641 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#81402} |
||
|---|---|---|
| .. | ||
| BUILD.gn | ||
| compiler-types.cc | ||
| debug-helper-internal.cc | ||
| debug-helper-internal.h | ||
| debug-helper.h | ||
| debug-macro-shims.h | ||
| DEPS | ||
| gen-heap-constants.py | ||
| get-object-properties.cc | ||
| heap-constants.cc | ||
| heap-constants.h | ||
| list-object-classes.cc | ||
| OWNERS | ||
| README.md | ||
V8 debug helper
This library is for debugging V8 itself, not debugging JavaScript running within V8. It is designed to be called from a debugger extension running within a native debugger such as WinDbg or LLDB. It can be used on live processes or crash dumps, and cannot assume that all memory is available in a dump.