The current specification has GeneratorFunction() be like Function(),
except that it makes generator instances. This commit implements that
behavior. It also fills in a piece of the implementation where
otherwise calling GeneratorFunction or GeneratorFunctionPrototype would
cause an abort because they have no code.
R=mstarzinger@chromium.org, rossberg@chromium.org
TEST=mjsunit/harmony/generators-iteration
TEST=mjsunit/harmony/generators-runtime
BUG=v8:2355
BUG=v8:2680
Review URL: https://codereview.chromium.org/14857009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Running with ASAN needs more stack, so don't set resource constraints too
tight.
* Checking boot time memory usage doesn't make sense when running with ASAN,
it eats tons of memory for itself.
* Fixed a malloc/delete[] mismatch: Not surprisingly, the pointer wrapped by
a SmartArrayPointer should better be allocated by, well, NewArray...
Even with these 3 fixes, we still have a few failures when running our test
suite with ASAN. Most of them are either timeouts or failures caused by greatly
increased stack usage.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/15096011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14674 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Stack iterator takes return address based on the frame pointer (ebp) and detects JS frames based on value at fp + StandardFrameConstants::kMarkerOffset. So in order the iterator to work correctly this values should be already setup for the current function. Stack frame is constructed at the very beginning of JS function code and destroyed before return. If sample is taken before before the frame construction is completed or after it was destroyed the stack iterator will wrongly think that FP points at the current functions frame base and will skip callers frame. To avoid this we mark code ranges where stack frame doesn't exist and completely ignore such samples.
This fixes cctest/test-cpu-profiler/CollectCpuProfile flakiness.
BUG=v8:2628
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/14253015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14670 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=rossberg@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14582007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14669 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ES3 specified that functions created via Function() would have
enumerable prototypes, unlike function literals. For this reason, V8
has always had two prototypes for functions: "function_map" for
literals, and "function_instance_map" for "function instances": those
functions created by Function().
However, since 2009 or so, both maps have been the same! Both have had
writable, non-enumerable prototypes. Moreover, ES5 changed to specify
that function instances would have non-enumerable prototypes.
This patch removes the separate maps for function instances in sloppy
and strict mode.
R=mstarzinger@chromium.org
TEST=mjsunit/function-prototype
BUG=
Review URL: https://codereview.chromium.org/14829005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a resubmit of codereview.chromium.org/13818012 with the following modifications:
- src/x64/code-stubs-x64.cc for changes specific to Win64 calling conventions.
- src/sampler.cc for Native Client support
BUG=v8:2614
Review URL: https://codereview.chromium.org/14305029
Patch from Brad Chen <bradchen@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14491 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Replace the 'unable_to_parse' key used in three places with three difference keys.
Provide three more informative and less ambiguous error messages in place of 'Parse error'.
Add three test/message cases to cover the new messages.
BUG=2636
Review URL: https://codereview.chromium.org/14161007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14462 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL extends the generator suspend and resume implementation to
capture values on the operand stack.
It factors out some helpers to measure and access the operand stack into
the JavaScriptFrame class. It also refactors the suspend and resume
helpers to avoid handle allocation.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14348003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes it so that suspending generators always saves the
context. Previously we erroneously assumed that if the operand stack
was empty, that the context would be unchanged, but that is not the case
with "with".
Fixing this brought out an interesting bug in the variable allocator.
Yield inside with will reference a context-allocated temporary holding
the generator object. Before the fix, this object was looked up in the
with context instead of the function context, because with contexts were
not being simulated during full-codegen. Previously this was OK as all
variables would be given LOOKUP allocation instead of CONTEXT, but the
context-allocated temporary invalidated this assumption. The fix is to
simulate the context chain more accurately in full-codegen.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14416011
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14454 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ia32, unlike the other architectures, includes a --debug-code check that
asserts that runtime functions do not return the hole. However the new
SuspendJSGeneratorObject runtime does return the hole at times.
This CL adds a wee hack that only signals an error if the callee was not
SuspendJSGeneratorObject.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/13856011
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously there has been no reason to context-allocate the receiver, so
access to the receiver always goes through the stack. This was failing
with generators, which assumed that forcing context allocation would
relieve the need of storing anything but the context and the function on
the stack.
This CL adds a slot in generator objects to capture the receiver, and
restores it when resuming a generator.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14158006
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The generator object methods "next", "send", and "throw" now
include some inline assembly to set up a resumed stack frame. In some
common cases, we can just jump back into the frame to resume it.
Otherwise the resume code calls out to a runtime to fill in the operand
stack, rewind the handlers, and possibly to throw an exception.
BUG=v8:2355
TESTS=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14066016
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Revert part of r14179. From the regression test's comment:
Currently, the gap resolver doesn't handle moves from a ConstantOperand to a
DoubleRegister, but these kind of moves appeared when HConstant::EmitAtUses
was changed to allow special double values (-0, NaN, hole). So we should
either enhance the gap resolver or make sure that such moves don't happen.
BUG=chrome:234101
Review URL: https://codereview.chromium.org/14429002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/ast.h:
* src/parser.cc: Differentiate between the different kinds of yields, in
anticipation of boxing return values. Parse `return' into `yield' in
a generator.
* src/runtime.h:
* src/runtime.cc (Runtime_SuspendJSGeneratorObject): New horrible
runtime function: saves continuation, context, and operands into the
generator object.
* src/arm/full-codegen-arm.cc (VisitYield):
* src/ia32/full-codegen-ia32.cc (VisitYield):
* src/x64/full-codegen-x64.cc (VisitYield): Arrange to call
SuspendJSGeneratorObject. If the call returns the hole, we suspend.
Otherwise we resume.
BUG=v8:2355
TEST=These codepaths are tested when the generator is first invoked, and so
are covered by mjsunit/harmony/generators-objects.js.
Review URL: https://codereview.chromium.org/13704010
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14353 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Generator object maps now link to their constructors, which are created
with a "Generator" class name. This does not cause a per-generator
constructor property to be set.
BUG=v8:2355
TEST=mjsunit/harmony/generators-objects
Review URL: https://codereview.chromium.org/14262004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14309 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When defining an indexed property on an Array object, the object's
length property should (perhaps) be updated. This was done for any
property for which
ToUInt32(name) == ToNumber(name)
was true, meaning any property name that, when converted to a number,
was an integer in the range [0, 2^32). The detection should be more
strict; an indexed property is one for which
ToString(ToUInt32(name)) == name
is true only.
Review URL: https://codereview.chromium.org/13914003
Patch from Jens Lindström <jl@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14242 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/contexts.h:
* src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
meta-objects, and store maps for constructing generator functions
and their prototypes.
* src/factory.h:
* src/factory.cc (MapForNewFunction): New helper.
(NewFunctionFromSharedFunctionInfo): Use the new helper.
* src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
generators, allocate appropriate prototypes and maps.
* src/code-stubs.h:
* src/arm/code-stubs-arm.h:
* src/arm/full-codegen-arm.h:
* src/ia32/code-stubs-ia32.h:
* src/ia32/full-codegen-ia32.h:
* src/x64/code-stubs-x64.h:
* src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
using the appropriate map.
* test/mjsunit/harmony/builtins.js: Add a special case for
GeneratorFunctionPrototype.prototype.__proto__.
BUG=
TEST=mjsunit/harmony/generators-runtime
Review URL: https://codereview.chromium.org/13192004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Specifically:
- Introduce Symbol and SymbolObject classes.
- Generalise Object::Has and Object::Delete to arbitrary Value-typed keys.
- Generalise some places in the API implementation from String to Name.
It is not possible to intercept symbol-named properties. That is consistent with the idea that symbols are private and should not leak.
R=svenpanne@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/13626002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14210 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The new test checks full CPU profiling cycle: using public
V8 API it starts profiling, executes a script, stops profiling
and analyzes collected profile to check that its top-down
tree has expected strutcture. The script that is being profiled
is guaranteed to run > 200ms to make sure enough samples
are collected.
To avoid possible flakiness due to non-deterministic time required
to start new thread on varios OSs when Sampler and ProfilerEventsProcessor
threads are being started the main thread is blocked until the threads
are running.
Also I removed the heuristic in profile-generator.cc where we try
to figure out if the value on top of the sampled stack is return address
of some frameless stub invocation. The code periodically gives false positive
with the new test ending up in an extra node in the collected cpu profile.
After discussion with jkummerow@ we concluded that the logic is too fragile
and that we can address frameless stub invocations in a more reliable way
later should they have a noticeable effect on cpu profiling.
BUG=None
Review URL: https://codereview.chromium.org/13627002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14205 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently, when a long series of removable simulates are merged, we do
this by merging them one by one as we find them. As we merge the value
value lists of the simulates, those lists snowball so that we get a
quadratic complexity wrt runtime and memory consumption.
Instead, we gather simulates that need to be merged, and merge them
backwards starting from the last simulate.
R=jkummerow@chromium.org
BUG=v8:2612
Review URL: https://chromiumcodereview.appspot.com/13649003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14169 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/scopes.h (ForceContextAllocation, has_forced_context_allocation):
New interface to force context allocation for an entire function's
scope.
* src/scopes.cc: Unless a new scope is a function scope, if its outer
scope has forced context allocation, it should also force context
allocation.
(MustAllocateInContext): Return true if the scope as a whole has
forced context allocation.
(CollectStackAndContextLocals): Allow temporaries to be
context-allocated.
* src/parser.cc (ParseFunctionLiteral): Force context allocation for
generator scopes.
* src/v8globals.h (VariableMode): Update comment on TEMPORARY.
* src/arm/full-codegen-arm.cc (Generate):
* src/ia32/full-codegen-ia32.cc (Generate):
* src/x64/full-codegen-x64.cc (Generate): Assert that generators have no
stack slots.
* test/mjsunit/harmony/generators-instantiation.js: New test.
BUG=v8:2355
TEST=mjsunit/harmony/generators-instantiation
Review URL: https://codereview.chromium.org/13408005
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14152 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch refactors the parser and preparser interface to be more
readable and type-safe. It has no behavior changes.
Previously, parsers and preparsers were configured via bitfield called
parser_flags in the Parser constructor, and flags in
PreParser::PreParseProgram, ParserApi::Parse, and ParserApi::PreParse.
This was error-prone in practice: six call sites passed incorrectly
typed values to this interface (a boolean FLAG value, a boolean false
and a boolean true value). None of these errors were caught by the
compiler because it's just an "int".
The parser flags interface was also awkward because it encoded a
language mode, but the language mode was only used to turn on harmony
scoping or not -- it wasn't used to actually set the parser's language
mode.
Fundamentally these errors came in because of the desire for a
procedural parser interface, in ParserApi. Because we need to be able
to configure the parser in various ways, the flags argument got added;
but no one understood how to use the flags properly. Also they were
only used by constructors: callers packed bits, and the constructors
unpacked them into booleans on the parser or preparser.
The solution is to allow parser construction, configuration, and
invocation to be separated. This patch does that.
It passes the existing tests.
BUG=
Review URL: https://codereview.chromium.org/13450007
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
