This adds a new per-compartment implementation of breakpoints and
reimplements the jsdbgapi.h "trap" entry points on top of it. Most
jsdbgapi.h-using code will still work, but there is no longer a single
runtime-wide trapList protected by a lock. Embeddings must follow the
compartment rules for thread safety.
JS_ClearAllTraps was removed, replaced by the per-compartment API
JS_ClearAllTrapsForCompartment.
The new implementation asserts that the PC passed to JS_SetTrap is
actually an offset of an instruction, not just a random number. This
caused quite a few tests to fail; fixes are included.
Added Debug.Script.prototype.setBreakpoint, getBreakpoints,
clearBreakpoint, and clearAllBreakpoints; and
Debug.prototype.clearAllBreakpoints.
In addition to tests targeting the new functionality, this changeset
includes some tests for Debug.Script.prototype.getLineOffsets, which is
hard to test without breakpoints.
This adds support for cross-compartment WeakMaps and changes js::Debug::objects to be one. It eliminates the vexing JSMSG_DEBUG_STREAMS_CROSSED error messsage.
The GC interaction between jsgc and jsdbg is a little more complex now; like the cross-compartment wrapper maps, Debug::objects must be marked (just once) during per-compartment GC. In other ways this is a simplification.
This allows most of the tests to run without the -d command-line flag.
Now a compartment is in debug mode if
* JSD1 wants debug mode on, thanks to a JS_SetDebugMode* call; OR
* JSD2 wants debug mode on, because a live Debug object has a debuggee
global in that compartment.
Since this patch only adds the second half of the rule, JSD1 should be
unaffected.
The new rule has three issues:
1. When removeDebuggee is called, it can cause debug mode to be turned
off for a compartment. If any scripts from that compartment are on
the stack, and the methodjit is enabled, returning to those stack
frames will crash.
2. When a Debug object is GC'd, it can cause debug mode to be turned off
for one or more compartments. This causes the same problem with
returning to deleted methodjit code, but the fix is different: such
Debug objects simply should not be GC'd.
3. Setting .enabled to false still does not turn off debug mode
anywhere, so it does not reduce overhead as much as it should.
A possible fix for issue #1 would be to make such removeDebuggee calls
throw; a different possibility is to turn off debug mode but leave all
the scripts alone, accepting the performance loss (as we do for JSD1 in
JSCompartment::setDebugModeFromC). The fix to issues #2 and #3 is to
tweak the rule--and to tweak the rule for Debug object GC-reachability.
--HG--
rename : js/src/jit-test/tests/debug/Debug-ctor.js => js/src/jit-test/tests/debug/Debug-ctor-01.js
Remove WeakMap class; implement the JavaScript object using functions static to jsweakmap.cpp.
Define a new WeakMap class template, parameterized by Key and Value types,
and accepting a MarkPolicy argument saying how to mark them.
Add assertions to check that we check and set the right mark bits, and
tests that trip them in the presence of mistakes in earlier revisions of
this patch.
This allows most of the tests to run without the -d command-line flag.
Now a compartment is in debug mode if
* JSD1 wants debug mode on, thanks to a JS_SetDebugMode* call; OR
* JSD2 wants debug mode on, because a live Debug object has a debuggee
global in that compartment.
Since this patch only adds the second half of the rule, JSD1 should be
unaffected.
The new rule has three issues:
1. When removeDebuggee is called, it can cause debug mode to be turned
off for a compartment. If any scripts from that compartment are on
the stack, and the methodjit is enabled, returning to those stack
frames will crash.
2. When a Debug object is GC'd, it can cause debug mode to be turned off
for one or more compartments. This causes the same problem with
returning to deleted methodjit code, but the fix is different: such
Debug objects simply should not be GC'd.
3. Setting .enabled to false still does not turn off debug mode
anywhere, so it does not reduce overhead as much as it should.
A possible fix for issue #1 would be to make such removeDebuggee calls
throw. The fix to issues #2 and #3 is to tweak the rule--and to tweak
the rule for Debug object GC-reachability.
--HG--
rename : js/src/jit-test/tests/debug/Debug-ctor.js => js/src/jit-test/tests/debug/Debug-ctor-01.js
Previously, JS_DefineProfilingFunctions only defined a very basic set of
functions (startProfiling and stopProfiling), and various scattered places
added more specific ones (start/stop vtune, dumpProfile, etc.) This patch makes
jsdbgapi do all of it, so that all users get the same set.
Also rename JS_DumpProfile -> JS_DumpBytecode to avoid name conflict. The
bytecode dumps are how the counters ("profiles") are displayed, so the
DumpProfile name was bogus anyway.
--HG--
extra : rebase_source : 2d3e626ef43ac41c6da401a779775a63fc96a427
mozalloc_undef_macro_wrappers are brittle and have side-effects that are hard
to debug and fix. The alternative is the just stick an underscore on the end of
malloc, free, etc, which is a comparatively small burden.
This changes the allocation API, in the following way:
js_malloc -> {cx->,rt->,OffTheBooks::}malloc
js_calloc -> {cx->,rt->,OffTheBooks::}calloc
js_realloc -> {cx->,rt->,OffTheBooks::}realloc
js_free -> {cx->,rt->,Foreground::,UnwantedForeground::}free
js_new -> {cx->,rt->,OffTheBooks::}new_
js_new_array -> {cx->,rt->,OffTheBooks::}new_array
js_delete -> {cx->,rt->,Foreground::,UnwantedForeground::}delete_
This is to move as many allocations as possible through a JSContext (so that they may be aken into account by gcMallocBytes) and to move as many deallocations to the background as possible (except on error paths).
