This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lots of web pages have really frequently firing timers that keep the
profiler thread spinning if we require a period of JS inactivity
before suspending the profiler. While it's possible to throttle it by
increasing the sleep delay and adjusting the duration of the required
inactive period, it seemed much simpler to just stop it immediately on
exiting JS.
Stopping the profiler this way effectively turned off two optimization
heuristics: 1) eager optimization (it's reset on waking up the
profiler and now the profiler wakes up much more frequently) and 2)
optimization throttling based on JS to non-JS state ratio (the ratio
is now 100%). I removed these two heuristics and found no performance
regressions so far.
R=ager@chromium.org
BUG=crbug.com/77625
TEST=none
Review URL: http://codereview.chromium.org/7274024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds an additional step to full gc, removing code from functions
that are no longer in the compilation cache. The code is replaced with
a lazy compile version enabling us to recompile the function in case
we do actually need it again.
Review URL: http://codereview.chromium.org/2632003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4814 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. The tables array allocated in the CompilationSubCache constructor
was never deallocated. Fixed by adding destructor.
2. The buffer allocated in one of the constructors of the
NoAllocationStringAllocator was never deallocated. It seems that
this class sometimes owns the buffer (if it allocated one itself)
and sometimes doesn't (if it was passed one). Simple fix is to
remove the offending constructor which was never used anyway.
Review URL: http://codereview.chromium.org/155917
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2520 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
surrounding context to figure out if the variable could be global. If
the variable could be global we check context extension objects at
runtime and use a global LoadIC if no variables have been introduced
by eval.
Fix crash bug when loading function arguments from inside eval. The
shadowed variable in the DYNAMIC_LOCAL case does not rewrite to a slot in
that case.
Review URL: http://codereview.chromium.org/28027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Changed the structure of regexp objects from having two internal
fields to having a single field containing a fixed array, since it's
easier to store the whole fixed array in the cache.
- Move printing of the command to after printing std{err,out} in the
compact progress indicators in the test framework.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@579 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
it for scripts too. In the context of Chromium, this should
have a very positive impact on memory consumption for web apps
that run multiple tabs from the same domain with a lot of the
same JavaScript code.
For now, the cache retirement policy is really simple:
Whenever a mark-sweep collection is started we clear the
cache. This guarantees that this change will not have a
huge negative impact on memory consumption, but it may
not be ideal. We should consider a more sophisticated LRU
scheme.
Review URL: http://codereview.chromium.org/1933
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
