Was hoping to catch a bug from D891329. Only caught a benign
use-after-pop of an ActRec in the unwinder. Maybe worth it anyway?
Reviewed By: @edwinsmith
Differential Revision: D907772
Gets HphpArrays into a flat mode using MM().objMalloc()
instead of SmartAllocator. Various optimizations were needed to the
Make functions to get this to work out ok. Growth still creates a
non-flat HphpArray (leaving a PromotedPayload behind so we know how
big the original allocation was).
Reviewed By: @edwinsmith
Differential Revision: D969431
Currently, a call to an async function returns a (Continuation)WaitHandle
object but the excution of the function body doesn't start before await
(or join()) on the WaitHandle is called. This changes it to start the
execution immediately and the control is returned to the caller only
after it's blocked.
Differential Revision: D946914
Aside from instance bits this is pretty straight forward.
Most of the other friends were just directly accessing members instead
of using accessors.
Differential Revision: D953599
This diff fixes some bugs with invokeFunc() and invokeFuncFew(), it removes
some dead code, and it converts more places to use cellDup() instead of
tvDup().
invokeFunc() had a bug where the VM stack did not get cleaned up properly
when a warning is raised and the user error handler threw an exception.
This diff adds a catch clause that will perform the appropriate cleanup and
then rethrow the exception.
invokeFuncFew() had a bug where in some cases it would pass a parameter by
reference when the callee required that the parameter be passed by value.
This was happening because TypedValues that were KindOfRef would get copied
onto the VM stack using operator=, and nothing was checking whether the
callee required the parameter to be passed by value. This diff fixes the
issue by reworking invokeFuncFew() and callers of invokeFuncFew().
Differential Revision: D949251
We currently don't have a way to type XHP's {} operator (i.e. to type $foo in
function ($foo) {
return <div>{$foo}</div>;
}
An XHPChild interface should solve this issue by having a type which is compatible with arrays, strings,
ints and doubles. We can then modify www to have :x:base implement XHPChild.
To me, this seems like the right step to get rid of the Xhp special casing.
Differential Revision: D886565
Translator modularization. Mostly mechanical code motion,
with addition of some documentation and better logging (disasm
support, etc). It's possible that the set of stubs for ARM vs x64
might not be exactly the same eventually, but it might, so for now
this is layed out with the assumption that a future
unique-stubs-arm.cpp will populate the same list of stubs. (I also
tried drawing the line on a per 'stub group' basis, but too many stubs
have tricks about layout and it seemed hard to predict whether that
would commonize anything other than the function call loop, so we can
do it later as needed.) Also rename the JIT::CodeGenHelpersX64
namespace to JIT::X64.
Differential Revision: D942874
evalPHPDebugger catches and suppresses all exceptions except debugger exceptions. Hence the catch clauses that follow its only call site are dead code, except for the catch all, which seems just wrong to me since it suppresses Debugger exceptions that are explicitly propagated by evalPHPDebugger.
Differential Revision: D945652
The code to print out the result of the expression following the = command has moved from inside the resulting eval block, to outside it in the debugger code itself. Hence, if the eval block fails, the value of $_ now prints out and this is confusion because it is the value that a previous = command put in there. With this change the eval block first unsets $_, so that the subsequent print value code will do nothing in the case of a failure.
Differential Revision: D944120
fCallArrayhelper smashes its return address, leading to
return branch mispredictions until we return enough times to get back
on track. Rewrite it as an asm stub so it can make a tail jump and
pop the proper return ip into the ActRec.
Differential Revision: D941930
The C++ vtable pointers and the m_cls pointers in ObjectData are
redundant for C++ extension classes; they both indicate the ObjectData's
dynamic type.
This diff gives ObjectData the same treatment that the ArrayData
hierarchy got, replacing virtual functions with manual dispatch based on
attributes and m_cls. We can't do direct comparison against m_cls,
because of inheritance, except when we know inheritance is not in the
picture.
The vtable isn't gone yet, because I need to do something about C++
destructors, which still require virtual dispatch. That's going to
require a lot of grunt work, so I wanted to put this diff up to keep
that stuff separate.
I did, however, make ~ObjectData non-virtual and try to compile, to
flush out all the dynamic_casts of ObjectData.
- The type-casting functions and clone() are pretty straightforward. The
only trick is that specialized clone() functions now have to call
cloneImpl() instead of the base class' clone(), otherwise infinite
recursion. I added an ObjectData attribute to indicate whether clone()
is special.
- t___{sleep,wakeup} didn't even need to be virtual, it turns out.
ObjectData's implementation goes through the normal PHP-method lookup
path, which effectively does virtual dispatch and routes us to any
specialized implementations anyway.
Differential Revision: D940852
function foo($bar, $baz) { }
foo();
Currently raises two errors:
foo() expects exactly 2 parameters, 0 given
foo() expects exactly 2 parameters, 1 given
Only the first of these is either meaningful or correct.
Stop reporting once we've raised it.
Differential Revision: D939810
If re-entry triggers stack overflow, there is no FCall or FCallArray,
so the code to find the pc in REQ_STACK_OVERFLOW would fail. If it
managed to get through there, it would then try to DecRef the contents
of an ActRec, sometimes causing it to DecRef a Func.
In addition, if a "leaf" function resulted in re-entry we didn't
necessarily check the stack.
Differential Revision: D936843
Since D898769, all locals in generator bodies have the same ids
as in the corresponding 'create generator' methods, so the mapping
between these ids is no longer needed.
Differential Revision: D932354
fast absolute value computation and related optimizations
implemented Abs in interpreter
implemented Abs in codegen
added const folding for abs
updating docs
adding new test for abs()
Differential Revision: D896037
- segfault handler never panned out and has been off for 1.5
years; cheaper to resurrect later from git than refactor to take it out
of tx64
Differential Revision: D922900
We should only call values() when we absolutely have to (magic calls where the array is not a vector)
Differential Revision: D920504
Blame Revision: D917994
- Eliminate Util::safe_strerror and use folly::errnoStr instead since the former is less safe as it doesn't preserve errno
Differential Revision: D920282
Test cases inspired by zend test bug35239.phpt. I think
there are other cases where SETOP_BODY should be SETOP_BODY_CELL, but
I looked at them mainly to see if they would crash, not if they were
optimal. (Except I changed SetOpL which seemed to be doing tvToCell
twice for no reason.)
Differential Revision: D910025
This is a step toward having StringData take control over how
it talks to the smart allocator based on its constructor parameters.
For now nothing is done to prevent allocation without going through
the new proxy function, but the nested allocator type is renamed to
prevent adding new uses of NEW or DELETE.
Differential Revision: D907959
The units that result from Eval code injected by the debugger should always be interpreted because they are used once only, however, any code invoked by these units should be JITtable. This diff moves the test for disabling the JIT from VMExecutionContext to Translator::isSrcKeyInB. It also fixes a cut&paste error that inverted the logic for Unit::isInterpretOnly().
Differential Revision: D913723
Blame Revision: D904873
The PHPUnit test suite calls get_defined_constants(true), for categorization. We threw. Now we don't. Now we actually do something sort of correct, but not fully correct. We have a "user" and "core" constant categorization. Function cleanup and consolidation. That's good. But Zend categorizes even more into extensions. This is a first step. And two (2) tests now move from zend/bad to zend/good.
Differential Revision: D909942
A number of debugger commands end up doing an eval inside the VM. These eval's are ad-hoc and are performed in human time scales. There is no need to cache them. Consequently, call compile_string directly, rather than call it via compileEvalString (which does caching). Also make sure that the result of compile_string is always interpreted so that no JIT caching happens.
In principle, caching ought not to matter, but another bug is causing the JIT to fail an assertion if a cached eval string is recompiled in a context where variables that were bound are no longer bound.
Differential Revision: D904873
Pushes the sqrt builtin down to codegen for ints and
doubles, which might help on some microbenchmarks, and adds
sqrtsd to the assembler.
Differential Revision: D898146
Inline some of the things into the TC so it can be
specialized on the closure type. Also avoids spilling everything to
the stack to call init (which just pulls it back off and puts it into
the heap), and uses AllocObjFast instead of newInstance. (We can't
quite get the super-fast-path version of AllocObjFast because closures
are extension objects and for now trying to convince it not to use the
m_InstanceCtor is a bit lame---we should probably just generate the
classes as php-level classes at some point so that'll just work.)
Differential Revision: D894569
We had both "prologue" and "prolog" all over the place, and it was
starting to drive me nuts. I picked "prologue" because it seems to be
the more standard spelling. Both are valid in American English, but in
the rest of the English-speaking world, only "prologue" is standard.
Differential Revision: D904232
In HHVM we've been piggybacking resources on the KindOfObject machinery.
At the language level, resource is considered to be a different type than
object, and there are a number of differences in behavior between objects
and resources (ex. resources don't allow for dynamic properties, resources
don't work with the clone operator, the "(object)" cast behaves differently
for resources vs. objects, etc).
Piggybacking resources on the KindOfObject machinery has some downsides.
Code that deals with KindOfObject values often needs to check if the value
is a resource and go down a different code path. This makes things harder
to maintain and harder to keep parity with Zend. Also, these extra branches
hurt performance a little, and they make it harder for the JIT to do a good
job in some cases when its generating machine code that operates on objects.
This diff introduces a new DataType called "KindOfResource", it separates
ResourceData from ObjectData's inheritance hierarchy, introduces a new
smart pointer types called "Resource" and "SmartResource", updates the
runtime as appropriate, and kills some more dead code in ObjectData and
ResourceData. I've tried to keep behavior the same for the most part and
resisted the urge to fix existing bugs with resources.
Jordan DeLong