This moves the bailout point in the JSInliner up to a point where it is
still allowed to decide not to inline. Once the inlining decision has
been recorded with CompilationInfo::AddInlinedFunction, we should not
abort anymore.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1410023006
Cr-Commit-Position: refs/heads/master@{#31469}
The patch in https://crrev.com/ddb5c2d999c5ee6e31c4a9599bb3ddb293cc3f49
moved all fractional digit settings to default values due to a coding
error. These were not even correct default values, and users observed
errors where percentages were written as "23.0%" instead of "23%".
This patch fixes the setting propagation when appropriate and it changes
the default max fractional digits of a percentage to 0, per spec.
BUG=chromium:544122
R=mnita,jochen
CC=hichris123,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1420883002
Cr-Commit-Position: refs/heads/master@{#31468}
This will allow us to remove background idle notification calls in Chrome.
BUG=chromium:490559
LOG=NO
Review URL: https://codereview.chromium.org/1406303008
Cr-Commit-Position: refs/heads/master@{#31464}
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.
BUG=v8:4470
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1407913003 .
Cr-Commit-Position: refs/heads/master@{#31462}
Incremental GC now finish quickly in background tabs too because they
do not rely on idle notifications.
BUG=
Review URL: https://codereview.chromium.org/1423453003
Cr-Commit-Position: refs/heads/master@{#31461}
The plan is to implement the same idea using vector IC machinery.
Stubs implementations and scopes modifications are left untouched for now.
Review URL: https://codereview.chromium.org/1419823003
Cr-Commit-Position: refs/heads/master@{#31458}
Use a unified NamedAccess operator parameter for both JSLoadNamed and
JSStoreNamed, and similar use PropertyAccess for both JSLoadProperty and
JSStoreProperty.
Review URL: https://codereview.chromium.org/1418993002
Cr-Commit-Position: refs/heads/master@{#31456}
It appears we haven't wired in the 32 float constant passed on the stack.
BUG=v8:4506
LOG=n
Review URL: https://codereview.chromium.org/1407003015
Cr-Commit-Position: refs/heads/master@{#31453}
(With a v8::Vector, the client is responsible for memory management.
I think there can be a situation where the Vector has a char[1] backing
store with '\0' in it, in which case the current code would leak.
If we always Dispose() the backing store this should be avoided.
Since dispose will delete[] the actual backing store, this should
also work then the backing store is nullptr.)
R=jochen@chromium.org
BUG=chromium:525885
LOG=N
Review URL: https://codereview.chromium.org/1410543005
Cr-Commit-Position: refs/heads/master@{#31446}
This change adds new flavors of Visit() methods for obtaining
expression results:
- VisitForAccumulatorValue() which places result in the accumulator.
- VisitForRegisterValue() which places the result in a register.
- VisitForEffect() which evaluates the expression and discards the result.
The targets of these calls place the expression result with
result_scope()->SetResultInRegister() or
result_scope()->SetResultInAccumulator().
By being smarter about result locations, there's less temporary
register usage. However, we now have a hazard with assignments
in binary expressions that didn't exist before. This change detects and
DCHECK's when a hazard is detected. A follow on CL will address this.
There are consequential changes to test-bytecode-generator.cc and
this change also adds new bytecode macros A(x, n) and THIS(n) for
register file entries for arguments and this.
BUG=v8:4280
LOG=NO
Review URL: https://codereview.chromium.org/1392933002
Cr-Commit-Position: refs/heads/master@{#31445}
The newly introduced root makes sure that we do not flush the
optimized code while the function is being compiled.
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1415133002
Cr-Commit-Position: refs/heads/master@{#31444}
This reverts commit a31cef44dc.
Original message:
[heap] Divide available memory upon compaction tasks
- Fairly (round-robin) divide available memory upon compaction tasks.
- Ensure an upper limit (of memory) since dividing is O(n) for n free-space
nodes.
- Refill from free lists managed by sweeper once a compaction space becomes
empty.
Assumption for dividing memory: Memory in the free lists is sparse upon starting
compaction (which means that only few nodes are available), except for memory
reducer GCs, which happen in idle time though (so it's less of a problem).
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1421583002
Cr-Commit-Position: refs/heads/master@{#31443}
Set "no recover" in diagnostic mode to keep triggering
crashes. Otherwise, the v8 test driver won't notice tests
as failing.
Also port some common sanitizer cflags to cfi - those can be
removed on the build side afterwards.
BUG=chromium:515782
LOG=n
Review URL: https://codereview.chromium.org/1414763004
Cr-Commit-Position: refs/heads/master@{#31442}
Reason for revert:
Failing again: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/2183
Original issue's description:
> Reland of "[heap] Divide available memory upon compaction tasks"
>
> This reverts commit cf71c28f13.
>
> Original message:
>
> [heap] Divide available memory upon compaction tasks
> - Fairly (round-robin) divide available memory upon compaction tasks.
> - Ensure an upper limit (of memory) since dividing is O(n) for n free-space
> nodes.
> - Refill from free lists managed by sweeper once a compaction space becomes
> empty.
>
> Assumption for dividing memory: Memory in the free lists is sparse upon starting
> compaction (which means that only few nodes are available), except for memory
> reducer GCs, which happen in idle time though (so it's less of a problem).
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/63f42ecb965d04877f45043c1416170b6f79b962
> Cr-Commit-Position: refs/heads/master@{#31436}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1405273003
Cr-Commit-Position: refs/heads/master@{#31439}
This makes sure that initializing assignments of let-declared variables
perform an environment lookup and hence keep the variable alive. This is
needed because full-codegen contains debug code verifying the variable
is still inside the TDZ at the initializing assignment.
R=jarin@chromium.org
TEST=mjsunit/compiler/regress-variable-liveness-let
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1420573002
Cr-Commit-Position: refs/heads/master@{#31437}
This reverts commit cf71c28f13.
Original message:
[heap] Divide available memory upon compaction tasks
- Fairly (round-robin) divide available memory upon compaction tasks.
- Ensure an upper limit (of memory) since dividing is O(n) for n free-space
nodes.
- Refill from free lists managed by sweeper once a compaction space becomes
empty.
Assumption for dividing memory: Memory in the free lists is sparse upon starting
compaction (which means that only few nodes are available), except for memory
reducer GCs, which happen in idle time though (so it's less of a problem).
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1415733004
Cr-Commit-Position: refs/heads/master@{#31436}
When eagerly parsing arrow functions, expressions in default
parameter initializers are parsed in the enclosing scope,
rather than in the function's scope (since that scope does not
yet exist). This leads to VariableProxies being added to the
wrong scope, and scope chains for FunctionLiterals being incorrect.
This patch addresses these problems by adding a subclass of
AstExpressionVisitor that moves VariableProxies to the proper
scope and fixes up scope chains of FunctionLiterals.
This is a revert of the revert https://crrev.com/e41614a058426fb6102e4ab2dd4f98997f00c0fc
with a much-improved (though not yet perfect) Scope::ResetOuterScope
method which properly fixes not only the outer_scope_ pointer but also
fixes the inner_scope_ list in the relevant outer_scopes.
More work likely still needs to be done to make this work completely,
but it's very close to correct.
BUG=v8:4395
LOG=y
Review URL: https://codereview.chromium.org/1414283002
Cr-Commit-Position: refs/heads/master@{#31435}
Also clean up the access check, which was doing too much.
This is in preparation of implementing Reflect.getPrototypeOf.
BUG=
Review URL: https://codereview.chromium.org/1402973002
Cr-Commit-Position: refs/heads/master@{#31434}
port d515e5138d30ab5b2a79e4cac99fcc5ca8d8991b(r31211).
contributed by zhengxing.li@intel.com
original commit message:
Previously, name conflicts between var and let declarations were only made into exceptions if they were visible at parse-time. This patch adds runtime checks so that sloppy-mode direct eval can't introduce conflicting var declarations. The change is implemented by traversing the scope chain when a direct eval introduces a var declaration to look for conflicting let declarations, up to the function boundary.
additional comment:
The original r31211 patch needs some additional changes for x87
1. Should use Smi::FromInt(variable->DeclarationPropertyAttributes())
BUG=
Review URL: https://codereview.chromium.org/1420683002
Cr-Commit-Position: refs/heads/master@{#31433}
Revert "Revert of [turbofan] Splinter into one range.
(patchset #2 id:80001 of https://codereview.chromium.org/1391023007/ )"
This reverts commit 23a8837fcc.
Also added a CHECK in Merge to validate that splitting yields a different
range and thus advances the algorithm. Ran stress bots successfully. Likely my earlier change in Splintering addressed the stress test scenario
that was looping infinitely.
BUG=
Review URL: https://codereview.chromium.org/1406983004
Cr-Commit-Position: refs/heads/master@{#31430}
Rolling v8/build/gyp to 3f21260b43401553c37bb28090b65a75577d5b4e
Rolling v8/tools/swarming_client to b64f0423ee66e730b0ceb88de8b9b89a98d7b61a
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1417863002
Cr-Commit-Position: refs/heads/master@{#31429}
range's internal structure, we take a range at a time and splinter based on
the blocks it covers. This is no different in scenarios where a UseInterval
covers non-deferred then deferred blocks. However, in scenarios where
a deferred block jumps to another one, and there are no other blocks
covered by the range in between, this CL will treat the two such blocks
together, while the previous one would treat them separately. This matters
in cases such as deoptimization blocks preceded (not necessarily
consecutively) by a single instruction (jump) Merging block.
Review URL: https://codereview.chromium.org/1415833002
Cr-Commit-Position: refs/heads/master@{#31422}
It is not always safe to allocate new heap objects in the JSGraph. We
might have to revisit this later once we do the canonicalization for
HeapConstants.
R=jarin@chromium.org
BUG=chromium:545364
LOG=n
Review URL: https://codereview.chromium.org/1413373002
Cr-Commit-Position: refs/heads/master@{#31421}
