Since constant pools have been simplified such that they always follow
the load instructions referencing them, it is now possible to copy the
pool data into the main assembly buffer right away in finishPool()
instead of deferring the copy to executableCopy(). This has the
important effect that BufferOffset values don't need to be adjusted to
account for the size of injected constant pools.
- In finishPool(), copy the constant pool data into the main assembler
buffer with putBytesLarge() which allows the potentially large pool
data to be split over multiple slices.
- Stop copying pool data in executableCopy(). It has already
been copied in finishPool().
- Simplify the PoolInfo data structure to a simple (firstEntry, offset)
pair which records the necessary information about a single emitted
constant pool.
- Rewrite poolEntryOffset() to use the new PoolInfo data.
- Simplify poolSizeBefore() to just return 0. This function will be
removed entirely in a followup patch.
- Stop patching branches in executableCopy() and delete the
patchBranch() method. Since buffer offsets are reliable when the
branches are inserted and when labels are bound, there is no need to
adjust branches to account for constant pools.
- Delete the BufferSliceTail class. It is no longer necessary to
maintain a bit vector of branch instructions since we don't rewrite
branches any longer. Use the plain AssemblerBuffer::Slice class
instead.
This patch implements the basic functional change of copying pool data
immediately instead of deferring it. Followup patches will clean up the
now redundant code.
--HG--
extra : rebase_source : 719225aef25dbf1b4bb7561391224b3c5f8793a5
This new method copies a large amount of data into the assembler
buffer, potentially splitting it across multiple slices.
The existing putBytes() method can only copy into a single slice which
limits the maximum since of data that can be inserted and potentially
wastes space at the end of the previous slice.
--HG--
extra : rebase_source : aab678bd50e232a328748232ca039da7d063639a
This allows us from a child frame to go up one level. This is documented
at http://w3c.github.io/webdriver/webdriver-spec.html#switch-to-parent-frame
--HG--
extra : commitid : GtXAxWLM61v
extra : rebase_source : 9b18d51a5dbefb4dad1cb39b229dc3d55cfae26a
extra : histedit_source : d0a0479e0c9946f242efd71e722685447ae48fd1
The logging interface is moved to xpcom/base, a LogModule wrapper for PR_Log is
added, a thread-safe LogModuleManager is added, and a LazyLogModule class used
to lazily load log modules in a thread-safe manner is added.
--HG--
rename : xpcom/glue/Logging.h => xpcom/base/Logging.h
extra : rebase_source : 89b76664d9477e2c894448cdea4dae1c61f8ca24
Moving xpcom/glue/Logging.h to xpcom/base/Logging.h causes build failures in
signaling due to include conflicts. Rather than having signaling include
'xpcom/base' directly we can switch it over to using the installed headers
under 'mozilla'.
--HG--
extra : rebase_source : aff44b19c23a1948a9c03b2fd4886be6280422a7
In the one place we push a MediaRawDataQueue onto a MediaRawDataQueue,
we don't use the pushee aftewards. It's more efficient to indicate that
by using Move(), and we can then save on reference-counting things
needlessly.
Sometimes when we push onto the queue, we don't need to hold a reference
afterwards. In that case, we can pass the reference in and avoid
unnecessary reference counting.
Futures-proofs the Marionette Python client to have support for level
3 of the Marionette protocol outlined in bug 1211489.
This patch changes the marionette-transport API most notably by renaming
the MarionetteTransport class to TcpTransport and by splitting the
receive-capabilities of TcpTransport.send into a new function called
request.
Furthermore it introduces a message data structure for dealing with
incoming responses and commands, and for marshaling messages to send in
order to support all three protocol levels.
r=dburns
r=jgriffin
--HG--
extra : commitid : 3jwoFepZzgy
extra : rebase_source : 5012e774b6edf6a1d53db22e360b5a0b063dd59b
