This is a purely mechanical change, adding an Isolate* to the CodeStub
constructor and a corresponding field plus a getter. A few methods in
CodeStub and its subclasses can be simplified now, but this is done in
a separate CL.
The underlying reason apart from simplicity is that deep down in the
call chain we need to detect if the serializer is active or not. This
information will be part of the Isolate, not a global variable with
funky synchronization primitives around it (which is fundamentally
wrong and the underlying cause for race conditions and a catch-22
during initialization).
BUG=359977
LOG=y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/246643014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Throwing under FLAG_debug_code confuses the rest of our infrastructure
which expects a safe point at the site of call into the runtime
for throw. We were doing that to make a clusterfuzz test happy, but
the better solution is to assert/abort under debug_code, and prevent
clusterfuzz from fuzzing on internal APIs that crash on incorrect
values.
We'll need to alter the fuzzer to turn off fuzzing for:
string-natives.js
lithium/SeqStringSetChar.js
regress/regress-seqstrsetchar-ex3.js
regress/regress-seqstrsetchar-ex1.js
regress/regress-crbug-320922.js
So as to prevent the fuzzer from running
%_OneByteSeqStringSetChar() and
%_TwoByteSeqStringSetChar().
BUG=
R=hpayer@chromium.org, machenbach@chromium.org
Review URL: https://codereview.chromium.org/139903005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
call machinery. The change replaces CallNamed, CallKeyed,
CallConstantFunction and CallKnownGlobal hydrogen instructions with two
new instructions with a more lower level semantics:
1. CallJSFunction for direct calls of JSFunction objects (no
argument adaptation)
2. CallWithDescriptor for calls of a given Code object according to
the supplied calling convention.
Details:
CallJSFunction should be straightforward, the main difference from the
existing InvokeFunction instruction is the absence of argument adaptor
handling. (As a next step, we will replace InvokeFunction with an
equivalent hydrogen code.)
For CallWithDescriptor, the calling conventions are represented by a
tweaked version of CallStubInterfaceDescriptor. In addition to the
parameter-register mapping, we also define parameter-representation
mapping there. The CallWithDescriptor instruction has variable number of
parameters now - this required some simple tweaks in Lithium, which
assumed fixed number of arguments in some places.
The calling conventions used in the calls are initialized in the
CallDescriptors class (code-stubs.h, <arch>/code-stubs-<arch>.cc), and
they live in a new table in the Isolate class. I should say I am not
quite sure about Representation::Integer32() representation for some of
the params of ArgumentAdaptorCall - it is not clear to me wether the
params could not end up on the stack and thus confuse the GC.
The change also includes an earlier small change to argument adaptor
(https://codereview.chromium.org/98463007) that avoids passing a naked
pointer to the code entry as a parameter. I am sorry for packaging that
with an already biggish change.
Performance implications:
Locally, I see a small regression (.2% or so). It is hard to say where
exactly it comes from, but I do see inefficient call sequences to the
adaptor trampoline. For example:
;;; <@78,#24> constant-t
bf85aa515a mov edi,0x5a51aa85 ;; debug: position 29
;;; <@72,#53> load-named-field
8b7717 mov esi,[edi+0x17] ;; debug: position 195
;;; <@80,#51> constant-s
b902000000 mov ecx,0x2 ;; debug: position 195
;;; <@81,#51> gap
894df0 mov [ebp+0xf0],ecx
;;; <@82,#103> constant-i
bb01000000 mov ebx,0x1
;;; <@84,#102> constant-i
b902000000 mov ecx,0x2
;;; <@85,#102> gap
89d8 mov eax,ebx
89cb mov ebx,ecx
8b4df0 mov ecx,[ebp+0xf0]
;;; <@86,#58> call-with-descriptor
e8ef57fcff call ArgumentsAdaptorTrampoline (0x2d80e6e0) ;; code: BUILTIN
Note the silly handling of ecx; the hydrogen for this code is:
0 4 s27 Constant 1 range:1_1 <|@
0 3 t30 Constant 0x5bc1aa85 <JS Function xyz (SharedFunctionInfo 0x5bc1a919)> type:object <|@
0 1 t36 LoadNamedField t30.[in-object]@24 <|@
0 1 t38 Constant 0x2300e6a1 <Code> <|@
0 1 i102 Constant 2 range:2_2 <|@
0 1 i103 Constant 1 range:1_1 <|@
0 2 t41 CallWithDescriptor t38 t30 t36 s27 i103 i102 #2 changes[*] <|@
BUG=
R=verwaest@chromium.org, danno@chromium.org
Review URL: https://codereview.chromium.org/104663004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18626 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The %_OneByteSeqStringSetChar intrinsic expects its arguments to be checked before being called for efficiency reasons, but the fuzzer provided no such checks. Now the intrinsic is robust to bad input if FLAG_debug_code is set.
R=yangguo@chromium.org
TEST=test/mjsunit/regress/regress-320948.js
BUG=chromium:320948
LOG=Y
Review URL: https://codereview.chromium.org/72813004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17886 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Our generic KeyedStoreIC doesn't handle the case when a callback is
set on array elements in the prototype chain of the object, nor do
we recognize that we need to avoid the monomorphic case if these
callbacks exist.
This CL addresses the issue by looking for dictionary elements in
the prototype chain on IC misses and crankshaft element store
instructions. When found, the generic IC is used. The generic IC is
changed to go to the runtime in this case too.
In general, keyed loads are immune from this problem because they
won't return the hole: discovery of the hole goes to the runtime where
the callback will be found in the prototype chain. Double array loads
in crankshaft can return the hole but only if the prototype chain is
unaltered (we will catch such alterations).
Includes the following patch as well (already reviewed by bmeurer):
Performance regression found in test regress-2185-2.js. The problem was
that the bailout method for TransitionAndStoreStub was not performing
the appropriate transition.
(Review URL for the ElementsTransitionAndStoreIC_Miss change:
https://codereview.chromium.org/26911007)
R=danno@chromium.org
Review URL: https://codereview.chromium.org/35413006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change means that code which is never executed is garbage collected immediately, and code which is only executed once is collected more quickly (limiting heap growth), however, code which is re-executed is reset to the young age, thus being kept around for the same number of GC generations as currently.
BUG=280984
R=danno@chromium.org, hpayer@chromium.org
Review URL: https://codereview.chromium.org/23480031
Patch from Ross McIlroy <rmcilroy@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
