In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
The list of search plugins actually installed for the en-US locale is in
browser/locales/en-US/searchplugins/list.txt. It doesn't contain some of
the files that can be found in browser/locales/en-US/searchplugins, and
as a result, those files are installed when using `mach build faster`
because it doesn't rely on that list.txt file.
We might as well remove those unlisted search plugins. They can be found
in the repository history anyways, if necessary at some point in the
future.
For reference, they were removed from list.txt in bug 603298.
DONTBUILD NPOTB
This has always been possible with Gradle -- Gradle doesn't care where
in the file tree resources are found. (Gradle is perfectly happy to
take resources from outside of the root project directory.) IntelliJ,
however, displays resources outside of known "content roots" in
special and frankly unhelpful ways. Here, we avoid that on a
technicality: IntelliJ doesn't acknowledge (or even register a content
root!) for the non-standard AndroidManifest.xml locations set in
build.gradle. This means we don't see odd content roots in unexpected
places in IntelliJ.
With this change, the formerly failing command
mach clobber && mach configure && mach gradle-install
completes successfully. That gets us one step closer to being able to
open Fennec in IntelliJ without running additional commands.
DONTBUILD NPOTB
This needed the same dependency changes that the previous part did.
There's a nice simplification here because some of the code is now
being compiled in the containing project (base) and not the (now
removed) sibling project.
While testing, I found some issues with the existing dependencies. To
address them, I've made all project preBuild tasks depend on the
(single) root generateCodeAndResources; this should ensure that the
Make integration happens as early as possible. In addition, I fixed
the dependencies syncing the generated resources into the build
directory, which weren't quite right. This works well locally now.
We were both lazy and incomplete before. Lazy because .aapt.deps is a
sentinel, and doesn't necessarily see relevant changes, due to
timestamps and deletions. Incomplete because we never forced
generated Java code to be fresh.
The implemetation of Assembler::actualOffset() is now a no-op in all
targets, and it is no longer necessary to rewrite assembler buffer
offsets to their final form after finishing the assembler buffer.
- Delete Assembler::actualOffset() in all targets.
- Delete AsmJSModule::CodeRange::updateOffsets().
- Delete AsmJSModule::updateCodeOffset().
- Delete AsmJSModule::updateOffsets().
- Delete CodeOffsetLabel::fixup().
- Delete ICEnty::fixupReturnOffset().
- Delete LSafepoint::fixupOffset().
- Delete OsiIndex::fixUpOffset().
- Delete PCMappingEntry::fixupNativeOffset().
Also delete all code calling these functions.
The ARM assembler no longer needs to keep track of code offsets for
later translation to 'actual' offsets. The AssemblerBuffer offsets
are directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, and tmpJumpRelocations_.
The ARM64 assembler no longer needs to keep track of code offsets for
later translation to 'final' offsets. The AssemblerBuffer offsets are
directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, tmpJumpRelocations_, and
the finalOffset() method.
This method was used by the Assembler::actualOffset() methods to
translate buffer offsets from pre-pool to post-pool numbers. Since
pools are now injected immediately, there is no need to translate
offsets.
All the actualOffset() methods have become no-ops in all our supported
targets.
This is possible because we no longer PodCopy the pools.
Use a more reasonable size for the inline memory in the loadOffsets
vector (8 loads instead of 512). This saves stack space when a
MacroAssembler is created on the stack. Use a matching inline size of 8
entries for the poolData array itself.
Don't drop memory in Pool::reset() by calling placement new - call
Vector::clear() instead which hangs on to previously allocated memory
for use by the next pool.
Delete an unused array of pools in arm64/vixl/MozBaseAssembler-vixl.h.
Use a Vector with 8 preallocated slots and a LifoAllocPolicy allocating
from the parent AssemblerBuffer's lifoAlloc_. We'll rarely need more
than 8 constant pools in a single assembler.
We can't actually allocate memory from this->lifoAlloc_ in the
constructor, but it is OK to capture allocator references like the
Vector constructor does.
Add an assertion to initWithAllocator() to verify that we didn't
allocate anything from lifoAlloc_ before the MacroAssembler constructor
had a chance to install an AutoJitContextAlloc.
There is no longer a 1-1 correspondence between buffer slices and
constant pools. We no longer need the ability to truncate a buffer
slice prematurely.
This uses less memory.
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.
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.
