This is a bit unfortunate, but otherwise we would have to include
objects.h before message.h, since for the initialization of a Handle<T>,
the compiler checks that Object* can be assigned to T*. So it would
need to know about the inheritance for initializing Handle<Script> and
Handle<JSFunction>.
R=mstarzinger@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1872373002
Cr-Commit-Position: refs/heads/master@{#35626}
The guard in JSFunction::MarkForOptimization checking whether a function
is being debugged is overly protective. The compilation pipeline will
bailout itself in that circumstance. Having the runtime behave similar
makes sure the debugger observes a situation closer to reality.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1900743003
Cr-Commit-Position: refs/heads/master@{#35625}
This stops printing a log line for when a lookup in the optimized code
map did not yield a result. Logging such a negative result that will
inevitably trigger a compile anyways has little benefit and just spams
the console unnecessarily.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1904433002
Cr-Commit-Position: refs/heads/master@{#35623}
As the code on the blink side sits down, we realize we don't need isolate arg
anymore. As the heap tracer is set per isolate, it can actually be confusing if
the isolate passed as argument is always the same as the isolate the heap tracer
was set for. Wdyt?
BUG=468240
LOG=no
Review URL: https://codereview.chromium.org/1900953003
Cr-Commit-Position: refs/heads/master@{#35620}
Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
This avoids custom compilation of receiver handlers for api getters.
BUG=
Review URL: https://codereview.chromium.org/1895093002
Cr-Commit-Position: refs/heads/master@{#35616}
port d2b0a4b727 (r35606)
original commit message:
MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>
BUG=
Review URL: https://codereview.chromium.org/1897823005
Cr-Commit-Position: refs/heads/master@{#35611}
In a full mark-compact GC, instead of copying memory to old space for
pages that have more than X% live bytes, we just move the whole page over to old
space.
X=70 (default value)
BUG=chromium:581412
LOG=N
Review URL: https://codereview.chromium.org/1863983002
Cr-Commit-Position: refs/heads/master@{#35610}
This removes obsolete code that supports compiling without a shared
function info object. Even for top-level code compiled for live edit
such an object is allocated by now.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1896083002
Cr-Commit-Position: refs/heads/master@{#35609}
This switches CodeGenerator::PrintCode to be based on the allocated
shared function info instead of the function literal. This is possible
now that even live edit allocates a shared function info for scripts.
R=ishell@chromium.org
BUG=chromium:604375
LOG=n
Review URL: https://codereview.chromium.org/1901753002
Cr-Commit-Position: refs/heads/master@{#35605}
port d0ccddd032 (r35584)
original commit message:
Behind --ignition-generators. Does not yet support Turbofan.
BUG=
Review URL: https://codereview.chromium.org/1902663002
Cr-Commit-Position: refs/heads/master@{#35602}
If we have 2 phis with the exact same operand list, and the first phi is
used before the second one, via the operand incoming to the block
that defines the phi, and the second one's operand is defined (via a
parallel move) after the use, then the original operand will be assigned
to the first phi. This will lead to a spurious validation error.
To fix this, we look at the original pending assessment.
Review URL: https://codereview.chromium.org/1895013003
Cr-Commit-Position: refs/heads/master@{#35601}
Reason for revert:
Broke InterpreterCreateArguments test on Linux nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/6404
Original issue's description:
> 32-bit linux: Force 16-byte stack alignment.
>
> clang assumes 16-byte stack alignment, but incoming stack alignment isn't
> always guaranteed to be that way. It looks like v8 was lucky to not hit
> this so far.
>
> See https://crbug.com/418554 -- this makes v8's standalone config match
> Chromium. See also https://llvm.org/bugs/show_bug.cgi?id=21414
>
> Maybe it's possible to change the caller of OnEntryHook() to guarantee
> the right alignment, but matching Chromium's build flags here seems like
> a good idea in general.
>
> BUG=v8:4928
> LOG=n
>
> Committed: https://crrev.com/3afb3324941625559635380ef98a2ee73e370a0a
> Cr-Commit-Position: refs/heads/master@{#35597}
TBR=machenbach@chromium.org,rnk@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4928
Review URL: https://codereview.chromium.org/1895783004
Cr-Commit-Position: refs/heads/master@{#35599}
clang assumes 16-byte stack alignment, but incoming stack alignment isn't
always guaranteed to be that way. It looks like v8 was lucky to not hit
this so far.
See https://crbug.com/418554 -- this makes v8's standalone config match
Chromium. See also https://llvm.org/bugs/show_bug.cgi?id=21414
Maybe it's possible to change the caller of OnEntryHook() to guarantee
the right alignment, but matching Chromium's build flags here seems like
a good idea in general.
BUG=v8:4928
LOG=n
Review URL: https://codereview.chromium.org/1899783002
Cr-Commit-Position: refs/heads/master@{#35597}
This makes sure that the Compiler::CompileForLiveEdit API function uses
the common pipeline for top-level code. It ensures that a proper shared
function info object is allocated before compilation is triggered.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1900613002
Cr-Commit-Position: refs/heads/master@{#35590}
Binding bytecode_array to a CodeStubAssembler variable in CallEpilogue
was causing issues with the approach to inline code stubs into
interpreter bytecode handlers. Instead of doing this, just keep track of
whether a call has been made, and if so reload directly from the stack
frame when necessary.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1895063002
Cr-Commit-Position: refs/heads/master@{#35586}
Misattributed samples are strictly related to handlers, and the size
of this special group helps understand how accurate the profile is.
For these reasons, it makes more sense to always show this group.
LOG=N
BUG=v8:4899
Review URL: https://codereview.chromium.org/1895793002
Cr-Commit-Position: refs/heads/master@{#35585}
This should be a plain refactoring change with only negligible changes
to method semantics. The main aim is to improve readability of some API
method implementations.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1895033003
Cr-Commit-Position: refs/heads/master@{#35583}
This removes the helper function in question that side-steps the
interpreter without going through the canonical UseIgnition predicate.
Having such a function is dangerous as it hides paths that are not yet
covered by the interpreter (like live edit in this case).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1895763002
Cr-Commit-Position: refs/heads/master@{#35580}
