TEST=ctest/test-scanner-streams/CharacterStreams
BUG=

Review-Url: https://codereview.chromium.org/2415093002
Cr-Commit-Position: refs/heads/master@{#40637}

This CL adds simple implementation of break and stepping-related functionality
as required by the debug-step.js test. This includes

* stepOver, stepInto, stepOut
* setBreakPoint
* clearBreakPoint
* evaluate

Some of these, e.g. setBreakPoint are not fully implemented for all cases but
only for the ones we need right now.

One interesting result of this is that using the inspector protocol is roughly
14x slower for debug-step.js (14s instead of 0.5s). One cause of this seems to
be iteration over all object properties in toProtocolValue, which is used to
serialize JS objects before being sent over the wire (e.g. FrameMirrors).  This
is something that should be fixed at some point. In the meantime, the test now
runs 100 instead of 1000 iterations.

BUG=v8:5530

Review-Url: https://codereview.chromium.org/2447073007
Cr-Commit-Position: refs/heads/master@{#40636}

This adds a wrapper class around the inspector protocol for use in
debugger tests. The interface is intended to stay similar to the
currently exposed DebuggerContext.

Right now, we support adding a listener, (partial) handling of the
AfterCompile event, and enabling/disabling the debugger.

BUG=v8:5530

Review-Url: https://codereview.chromium.org/2451153003
Cr-Commit-Position: refs/heads/master@{#40635}

BUG=v8:5339

Review-Url: https://codereview.chromium.org/2452923002
Cr-Commit-Position: refs/heads/master@{#40634}

In the asm.js to wasm pipeline, we generate an entry function with
BUILTIN code, but still attached to a TYPE_NORMAL script.
This fix avoids trying to set a breakpoint there, resulting in a crash
on DCHECK(shared->HasDebugInfo()).

Also add two inspector tests to track regressions.

BUG=v8:5568
R=titzer@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2457433002
Cr-Commit-Position: refs/heads/master@{#40633}

  port 7d383be9 (r40608)

  original commit message:
  For inputs to truncating binary operations like <<, | or >>>, support
  all Oddballs not just undefined, true and false. This unifies treatment
  of these truncations in Crankshaft and TurboFan, and is very easy
  nowadays, since the memory layout of Oddball and HeapNumber is
  compatible.

BUG=

Review-Url: https://codereview.chromium.org/2450093007
Cr-Commit-Position: refs/heads/master@{#40632}

Converting INT_MIN to positive should cause overflow,
which was not being captured. Fixed the logic to detect
if value is equal to INT_MIN and set the overflow code
accordingly.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2446113013
Cr-Commit-Position: refs/heads/master@{#40631}

The first 32 root list items are a conscious choice in order for the
serializer to encode root references more efficiently.

R=hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2458603002
Cr-Commit-Position: refs/heads/master@{#40630}

BUG=chromium:659165

Review-Url: https://codereview.chromium.org/2455103002
Cr-Commit-Position: refs/heads/master@{#40629}

This change makes the embenchen/copy benchmark a factor of 2 faster and
brings back the performance loss through graph trimming.

R=titzer@chromium.org
CC=bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2453343002
Cr-Commit-Position: refs/heads/master@{#40628}

The reasons are:
1) Type feedback vectors are not shared between different native contexts and
   therefore the IC handler created for one native context will not be reused
   in other native context.
2) Access rights revocation is not supported at all, therefore given (1) once
   we pass the access check we don't have to check access rights again.

BUG=v8:5561

Review-Url: https://codereview.chromium.org/2455953002
Cr-Commit-Position: refs/heads/master@{#40627}

BUG=v8:5561

Review-Url: https://codereview.chromium.org/2449463002
Cr-Commit-Position: refs/heads/master@{#40626}

Port 7d383be9

Original commit message:

    For inputs to truncating binary operations like <<, | or >>>, support
    all Oddballs not just undefined, true and false. This unifies treatment
    of these truncations in Crankshaft and TurboFan, and is very easy
    nowadays, since the memory layout of Oddball and HeapNumber is
    compatible.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2455993002
Cr-Commit-Position: refs/heads/master@{#40625}

The assumptions that OSR code is installed on {JSFunction} objects no
longer holds with TurboFan and hence {assertOptimized} can report a
different result dependeing on how OSR code is treated. This is working
as intended.

R=mythria@chromium.org

Review-Url: https://codereview.chromium.org/2453313002
Cr-Commit-Position: refs/heads/master@{#40624}

See https://goo.gl/C9U1dL

BUG=chromium:617892

Review-Url: https://codereview.chromium.org/2452333002
Cr-Commit-Position: refs/heads/master@{#40623}

This is no longer used.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2454713003
Cr-Commit-Position: refs/heads/master@{#40622}

Unlike other variable allocation logic, MODULE allocation does
not depend on resolution. So in order to give hole check elimination
(which runs during resolution) access to the information "is this
variable an import", simply allocate all modules variables prior
to resolution.

BUG=v8:1569

Review-Url: https://codereview.chromium.org/2458653002
Cr-Commit-Position: refs/heads/master@{#40621}

The latter was left from a previous commit and not updated later to reflect the new name.

Review-Url: https://codereview.chromium.org/2447023004
Cr-Commit-Position: refs/heads/master@{#40620}

BUG=v8:5573

Review-Url: https://codereview.chromium.org/2458623002
Cr-Commit-Position: refs/heads/master@{#40619}

This patch moves promise specific runtime functions
to runtime-promise.cc from runtime-internal.cc

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2452833003
Cr-Commit-Position: refs/heads/master@{#40618}

This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.

R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2443573002
Cr-Commit-Position: refs/heads/master@{#40617}

R=jarin@chromium.org
BUG=chromium:659967

Review-Url: https://codereview.chromium.org/2453633005
Cr-Commit-Position: refs/heads/master@{#40616}

This patch refactors most of FulfillPromise runtime call out to a separate
function so that we can to it from PromiseReject runtime call.

This patch adds a PromiseStatus enum.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2451163003
Cr-Commit-Position: refs/heads/master@{#40615}

This reverts commit 35e4a03f.

BUG=

Review-Url: https://codereview.chromium.org/2454723002
Cr-Commit-Position: refs/heads/master@{#40614}

We used to point elsewhere, for instance the right-hand-side of an assignment.

Small limitation: Since variable proxies only have a start position, not an end
position, the best we can do is point at the first character.  (We cannot rely
on the scanner's last token position because Declare may be called long after
the variable has been scanned.)

R=adamk@chromium.org
BUG=v8:5572

Review-Url: https://codereview.chromium.org/2447143005
Cr-Commit-Position: refs/heads/master@{#40613}

Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.

BUG=v8:5512

Review-Url: https://codereview.chromium.org/2448933002
Cr-Commit-Position: refs/heads/master@{#40612}

BUG=

Review-Url: https://codereview.chromium.org/2451173002
Cr-Commit-Position: refs/heads/master@{#40611}

This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.

I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.

Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}

'[...] accessor properties who have the attributes { [[Enumerable]]:
false, [[Configurable]]: true } [...]'

BUG=v8:5566

Review-Url: https://codereview.chromium.org/2452913002
Cr-Commit-Position: refs/heads/master@{#40609}

For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.

R=yangguo@chromium.org
BUG=v8:5400

Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}

  port df981a9f (r40577)

  original commit message:
  The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
  conversion (except for the uses in HBranch and HCompareHoleAndBranch,
  which were confusing and useless anyways), so fix the naming to match
  that.

  Also properly integrate the handling of this flag with the existing
  truncation analysis that is run as part of the representation changes
  phase (i.e. where we already deal with truncating to int32 and smi).

  This is done in preparation of allowing Crankshaft to handle any kind
  of Oddball in the ToNumber truncation, instead of just undefined for
  truncation ToNumber and undefined or boolean for ToInt32. It also helps
  to make Crankshaft somewhat more compatible with the (saner)
  implementation in TurboFan.

BUG=

Review-Url: https://codereview.chromium.org/2456503003
Cr-Commit-Position: refs/heads/master@{#40607}

R=titzer@chromium.org,binji@chromium.org
BUG=v8:4614

Review-Url: https://codereview.chromium.org/2423883003
Cr-Commit-Position: refs/heads/master@{#40606}

BUG=657568
TEST=Manually, see bug report

Review-Url: https://codereview.chromium.org/2432163004
Cr-Commit-Position: refs/heads/master@{#40605}

This is a poor-man's solution to trigger page interactions.

BUG=

Review-Url: https://codereview.chromium.org/2455623002
Cr-Commit-Position: refs/heads/master@{#40604}

LOG=N
BUG=v8:4124

Review-Url: https://codereview.chromium.org/2453813002
Cr-Commit-Position: refs/heads/master@{#40603}

Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).

The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.

Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):

List type                       Zone memory used   Time taken
-----------------------------------------------------------------------
Zone array (for comparison)     131072 B

Ideally initialized ZoneList    131088 B           0.062ms

ChunkZoneList                   134744 B           0.052ms <--new thing

ZoneDeque                       141744 B

ZoneLinkedList                  393264 B

Initially empty ZoneList        524168 B           0.171ms <--right now

ChunkZoneList only push_front   524320 B

Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}

BUG=chromium:575167, v8:5507

R=rossberg@chromium.org,bradnelson@chromium.org
CC=ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2447013004
Cr-Commit-Position: refs/heads/master@{#40601}

R=ahaas@chromium.org,rossberg@chromium.org,binji@chromium.org,bradnelson@chromium.org
BUG=chromium:575167, chromium:659591

Review-Url: https://codereview.chromium.org/2440953002
Cr-Commit-Position: refs/heads/master@{#40600}

If there is no stack trace (which happens), then at least print the
location of the message.

R=titzer@chromium.org,ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2450253002
Cr-Commit-Position: refs/heads/master@{#40599}

Turbofan requires a different tuning when compared to crankshaft. Crankshaft
typically has faster compilation times when compared to turbofan. Hence,
added a new parameter, so that crankshaft and turbofan can be tuned
independently.

OSRing too soon is not good for performance, especially for sunspider
benchmarks. Since they are really small functions and optimizing them is
more expensive than just executing unoptimized code. Tuning the code size
threshold of the functions that can be OSRed from ignition.

BUG=v8:4280,chromium:659111

Review-Url: https://codereview.chromium.org/2445203003
Cr-Commit-Position: refs/heads/master@{#40598}