- 10 Mar, 2015 31 commits
-
-
mstarzinger authored
This reduces the size of the StackHandler by yet another word. We no longer need to keep track of the frame pointer, as the stack walk will be able to recalculate it. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/991893003 Cr-Commit-Position: refs/heads/master@{#27115}
-
loislo authored
The same idea as in https://codereview.chromium.org/984893003/ BUG=chromium:452067 LOG=n Review URL: https://codereview.chromium.org/997513003 Cr-Commit-Position: refs/heads/master@{#27114}
-
yurys authored
None of these fields is used in Blink. Embedder always can implement them using existing API. BUG=chromium:465651 LOG=Y Review URL: https://codereview.chromium.org/983833006 Cr-Commit-Position: refs/heads/master@{#27113}
-
loislo authored
BUG=chromium:452067 LOG=n R=svenpanne@chromium.org, jacob.bramley@arm.com, yurys@chromium.org Review URL: https://codereview.chromium.org/995813002 Cr-Commit-Position: refs/heads/master@{#27112}
-
Ben L. Titzer authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/979323005 Cr-Commit-Position: refs/heads/master@{#27111}
-
svenpanne authored
Doing a runtime call should always be better than totally giving up (unless we have fullcode-only intrinsics, which we'll probably never have). BUG=v8:3947 LOG=n Review URL: https://codereview.chromium.org/997543002 Cr-Commit-Position: refs/heads/master@{#27110}
-
mstarzinger authored
This makes sure that the pending message location is only tracked by the message object, as only this is saved for finally-blocks. The location information is duplicated and becomes stale. R=titzer@chromium.org TEST=maeh, not so much. Review URL: https://codereview.chromium.org/987353002 Cr-Commit-Position: refs/heads/master@{#27109}
-
jarin authored
BUG=chromium:465701 LOG=n R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/993773004 Cr-Commit-Position: refs/heads/master@{#27108}
-
hpayer authored
There are no stale store buffer pointers anymore. The sweeper thread can not be in conflict with store buffer processing. BUG= Review URL: https://codereview.chromium.org/993983002 Cr-Commit-Position: refs/heads/master@{#27107}
-
arv authored
The prototype of a class constructor function is read only. When we set computed property names we were ignoring this and we were overriding the property. Since the prototype is the only possible own read only property on the constructor function object we special case this so we do not have to check this for every property in the class literal. BUG=v8:3945 LOG=N R=mstarzinger@chromium.org, dslomov@chromium.org Review URL: https://codereview.chromium.org/985643003 Cr-Commit-Position: refs/heads/master@{#27106}
-
hpayer authored
We can do that now since we have the invariant that the store buffer always has valid slots after marking. BUG= Review URL: https://codereview.chromium.org/991853002 Cr-Commit-Position: refs/heads/master@{#27105}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/978983003 Cr-Commit-Position: refs/heads/master@{#27104}
-
mstarzinger authored
This reduces the size of the StackHandler by one word. We no longer need to keep track of the code object, as the stack walk finds it. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/985803002 Cr-Commit-Position: refs/heads/master@{#27103}
-
svenpanne authored
We can remove a few of them now (those which unconditionally bailout), but this will be done in a separate CL to see any impact separately. BUG=v8:3947 LOG=n Review URL: https://codereview.chromium.org/993963002 Cr-Commit-Position: refs/heads/master@{#27102}
-
v8-autoroll authored
Rolling v8/tools/clang to ed79fd57317ab9f09ce52a5e1c7424eebb80a73e BUG=chromium:464657 LOG=n TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/988623002 Cr-Commit-Position: refs/heads/master@{#27101}
-
Sven Panne authored
Note that this patch is not really a *solution*, it is just enough to make the undefined behavior unobservable. The real fix would be being much more correct about sizes and signedness in our code base... BUG=chromium:464657 LOG=n R=dcarney@chromium.org Review URL: https://codereview.chromium.org/995743002 Cr-Commit-Position: refs/heads/master@{#27100}
-
jarin authored
BUG=chromium:465645 LOG=n R=titzer@chromium.org Review URL: https://codereview.chromium.org/996663002 Cr-Commit-Position: refs/heads/master@{#27099}
-
bmeurer authored
BUG=v8:3952 LOG=n R=yangguo@chromium.org Review URL: https://codereview.chromium.org/997513002 Cr-Commit-Position: refs/heads/master@{#27098}
-
yurys authored
BUG=None LOG=Y Review URL: https://codereview.chromium.org/992193002 Cr-Commit-Position: refs/heads/master@{#27097}
-
marja authored
The bits in CompilerHints are accessed via FunctionKindBits, and on the other hand, with accessors defined by BOOL_ACCESSORS(SharedFunctionInfo, compiler_hints, is_accessor_function, kIsAccessorFunction) etc. So the bit order in FunctionKind must match CompilerHints. This is not causing problems (yet) because there's no accessor for these two bits, but if somebody adds one, things will go wrong. R=dslomov@chromium.org BUG= Review URL: https://codereview.chromium.org/988413002 Cr-Commit-Position: refs/heads/master@{#27096}
-
hpayer authored
Revert of Fix old space check in IsSlotInBlackObject. (patchset #1 id:1 of https://codereview.chromium.org/993513009/) Reason for revert: Breaks arm.debug. Original issue's description: > Fix old space check in IsSlotInBlackObject. > > BUG= > > Committed: https://crrev.com/4f865389bcecdff6aa56512fab3a147507a95a51 > Cr-Commit-Position: refs/heads/master@{#27090} TBR=ulan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/987303003 Cr-Commit-Position: refs/heads/master@{#27095}
-
loislo authored
We use slightly different schema for JumpTable on arm64 than for x64. We do a branch (B) to the JumpTable from the code, then a branch (B) to the end of jump table code and then branch to the deoptimizer code with putting the return address into lr register (Call which is actually Blr). As a result the 'from' address in Deoptimizer always points to the end of JumpTable code and we can get nothing from this information. 0) I moved save_doubles and needs_frame code out of for_loop. 1) I replaced B commands with Bl so we put different return addresses to lr register for the different jump table entries and replaced the final Call with Br which do not touch lr register. Also I removed the last_entry check so we will always do the Bl even for the last entry because we need the right address in lr. I don't think that this will affect the performance because it just one more branch for entire deopt mechanics. BUG=chromium:452067 LOG=n Review URL: https://codereview.chromium.org/984893003 Cr-Commit-Position: refs/heads/master@{#27094}
-
yangguo authored
R=svenpanne@chromium.org BUG=chromium:465564 LOG=N Review URL: https://codereview.chromium.org/996603002 Cr-Commit-Position: refs/heads/master@{#27093}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/994893002 Cr-Commit-Position: refs/heads/master@{#27092}
-
ulan authored
BUG= Review URL: https://codereview.chromium.org/916103005 Cr-Commit-Position: refs/heads/master@{#27091}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/993513009 Cr-Commit-Position: refs/heads/master@{#27090}
-
mstarzinger authored
R=jarin@chromium.org BUG=chromium:465663 LOG=n Review URL: https://codereview.chromium.org/989743004 Cr-Commit-Position: refs/heads/master@{#27089}
-
titzer authored
R=mstarzinger@chromium.org BUG=chromium:462775 LOG=Y Review URL: https://codereview.chromium.org/988423003 Cr-Commit-Position: refs/heads/master@{#27088}
-
dcarney authored
BUG= Review URL: https://codereview.chromium.org/993883002 Cr-Commit-Position: refs/heads/master@{#27087}
-
bmeurer authored
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize both Math.ceil and Math.floor, and use the JS inlining mechanism to inline Math.ceil into TurboFan code. Although we need to touch code outside of TurboFan to make this work, this does not affect the way we handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft the old-style builtin function id based inlining still kicks in first. Once this solution is stabilized, we can use it for Math.floor as well. And once that is settled, we can establish it as the unified way to inline builtins, and get rid of the specialized builtin function id based inlining at some point. Note that "builtin" applies to basically every piece of internal JavaScript/intrinsics based code, so this also applies to the yet to be defined JavaScript based code stubs and handlers. BUG=v8:3953 LOG=n R=yangguo@chromium.org,svenpanne@chromium.org Review URL: https://codereview.chromium.org/990963003 Cr-Commit-Position: refs/heads/master@{#27086}
-
bmeurer authored
Context specialization enables inlining (at least currently it is the only enabler for inlining), but inlining enables more possibilities for context specialization. So we really need to run them together. This is especially important with the "module based builtins" that we're working towards. BUG=v8:3952 LOG=n Review URL: https://codereview.chromium.org/988423004 Cr-Commit-Position: refs/heads/master@{#27085}
-
- 09 Mar, 2015 9 commits
-
-
dcarney authored
since the old style weakness is slated for removal, we might as well reuse the name to limit confusion. additionally I simplified the callback type to a enum to either get internal field values or not this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused. R=jochen@chromium.org, erikcorry@chromium.org BUG= Review URL: https://codereview.chromium.org/989153003 Cr-Commit-Position: refs/heads/master@{#27084}
-
balazs.kilvady authored
BUG= Review URL: https://codereview.chromium.org/988243004 Cr-Commit-Position: refs/heads/master@{#27083}
-
machenbach authored
BUG=chromium:464657 LOG=n TBR=jochen@chromium.org Review URL: https://codereview.chromium.org/990253002 Cr-Commit-Position: refs/heads/master@{#27082}
-
machenbach authored
BUG=chromium:464657 LOG=n Review URL: https://codereview.chromium.org/987063002 Cr-Commit-Position: refs/heads/master@{#27081}
-
svenpanne authored
Note that this is done only for consistency at this point in time. The change should probably have been in https://codereview.chromium.org/984963002/ already. BUG=v8:3947 LOG=n Review URL: https://codereview.chromium.org/992683002 Cr-Commit-Position: refs/heads/master@{#27080}
-
jochen authored
R=hpayer@chromium.org LOG=n BUG=none Review URL: https://codereview.chromium.org/990203002 Cr-Commit-Position: refs/heads/master@{#27079}
-
titzer authored
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code). BUG= Review URL: https://codereview.chromium.org/974213002 Cr-Commit-Position: refs/heads/master@{#27078}
-
marja authored
R=dslomov@chromium.org BUG= Review URL: https://codereview.chromium.org/977123002 Cr-Commit-Position: refs/heads/master@{#27077}
-
loislo authored
The original code always returned the first entry from RelocInfo that matched with bailout_id. But we may have a few different deopt reasons for one bailout_id. So we need to get the one which matches with a particular call from JumpTable. We can do this by checking not 'target_address' (it maps to bailout_id) but 'from' address which maps to a particular JumpTable entry. The test was reworked so it tests identical functions against different reasons. BUG=chromium:452067 LOG=n Review URL: https://codereview.chromium.org/984773003 Cr-Commit-Position: refs/heads/master@{#27076}
-