instead of direct_dependent_settings - with V8 headers
being included in other headers, the former works much better.
This is a configuration that is not used for Google Chrome
neither V8 buildbot, and has been tested for its intended
use case (Linux distributions).
BUG=none
Review URL: https://codereview.chromium.org/12378092
Patch from Paweł Hajdan Jr. <phajdan.jr@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13822 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the traditional MIPS naming scheme, "mips" is used for
big-endian mips and "mipsel" is used for little-endian mips.
In V8 the "mips" build is little-endian, so the "mips" target is
renamed to "mipsel" to be compliant with the traditional MIPS
naming scheme.
This change is also required for supporting the Chromium project on MIPS.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10695114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
Review URL: https://chromiumcodereview.appspot.com/10697015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Note that in order to build for 64bits mode, you'll have
to specify the target architecture explicitely, the default
is still 32bits for Mac OS X.
Example with make and gcc:
$ export GYP_GENERATORS=make
$ make dependencies
$ make -j 8 library=shared x64.release
Example with make and clang:
$ export GYP_GENERATORS=make
$ export CC=/usr/bin/clang
$ export CXX=/usr/bin/clang++
$ export GYP_DEFINES="clang=1"
$ make dependencies
$ make -j 8 library=shared x64.release
Example with xcode:
$ export GYP_GENERATORS=xcode
$ build/gyp_v8 -Dtarget_arch=x64
$ xcodebuild -project build/all.xcodeproj -configuration Release
Contributed by Filipe David Manana <fdmanana@gmail.com>
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9808065
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11199 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL:
- Adds a new trait parameter to LazyInstance to let it initialize the instance
without paying the cost of atomic operations (which are expensive on Mac).
This only works for users who don't care about thread-safety and this is now
the default initialization trait used by LazyInstance in v8.
- Reverts the changes that were made in r11010 in isolate.{cc,h}. That lets
Isolate's accessors be as cheap as they were before (but adds one static initializer).
- Adds OS::PostSetup() used to initialize the math functions which depend on CPU features.
That lets the math functions get rid of CallOnce().
BUG=118686
Review URL: https://chromiumcodereview.appspot.com/9873023
Patch from Philippe Liard <pliard@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is necessary in order to link v8_shell (for host) with the Android
toolchain.
Without it, the line in the makefile is:
$(builddir)/v8_shell: LD_INPUTS := $(OBJS) $(obj).host/v8/tools/gyp/libv8_snapshot.a $(obj).host/v8/tools/gyp/libv8_base.a
Now it appears as:
$(builddir)/v8_shell: LD_INPUTS := $(OBJS) $(obj).host/v8/tools/gyp/libv8_base.a $(obj).host/v8/tools/gyp/libv8_snapshot.a
and it successfully links.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9668013
Patch from Yaron Friedman <yfriedman@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11005 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All module expressions, and all variables that might refer to modules,
are assigned interfaces (module types) that are resolved using
unification. This is necessary to deal with the highly recursive
nature of ES6 modules, which does not allow any kind of bottom-up
strategy for resolving module names and paths.
Error messages are rudimental right now. Probably need to track
more information to make them nicer.
R=svenpanne@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/9615009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The old HashMap class had an explicit member to determine the allocation
policy. The template version matches the approach used already for
lists.
Cleanup some include dependencies and unnecessary forward declarations.
Cleanup some dead code from isolate.h and replace some HEAP macros
with GetHeap().
Review URL: https://chromiumcodereview.appspot.com/9372106
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
