The native collection classes aren't made to support derived classes, and it
would take some work to add such support. This diff adds a check to prevent
classes marked with <<__MockClass>> from deriving from a collection class.
Reviewed By: drussi
Differential Revision: D980050
Makes a number of changes:
- Binds each server thread to a numa node, and
sets its default allocation mode to that node
- Allocates a jemalloc arena for each node,
and selects the right one at thread startup (
to ensure that we don't get memory that was
previously allocated on a different node)
- Changes thread scheduling to alternate between
nodes
- Sets the default allocation strategy for the
main thread (and non-server threads) to
interleaved.
Reviewed By: @jdelong
Differential Revision: D974085
hhir used to do a slow exit whenever a surprise flag check
succeeded. This is fine for most things, but can be all sorts of bad news for
PHProf. This diff adds support for calling the surprise flag hooks without
leaving the trace, and should restore some sanity to profiling results.
Reviewed By: @markw65
Differential Revision: D985446
This was going to make Class 408 bytes, and it seemed
plausible that that could be causing some red cpu time numbers in a
early perflab, so as part of this diff change declInterfaces not to be
a std::vector to pay for it.
Reviewed By: @edwinsmith
Differential Revision: D979850
We're trying to make sure that destruction/sweeping of extensions is implemented properly. During sweeping there should be no reference decrementing and no smart memory freeing.
Reviewed By: @jdelong
Differential Revision: D932364
Use PackedArrayInit. Also, this function is only called when
there is no invName, but it was doing the magic call case in this case
(we null it first), so rename it and don't branch on that and move it
to the single caller. Also, it was using appendWithRef instead of
append, presumably because it used to be possible for it to be used
for non-magic calls or something. From what I can tell, __call can
never get the argument array with reference members (if it can, the
translator is the one doing it wrong).
Reviewed By: @markw65
Differential Revision: D972302
Also, add comments on the other ones I've found for ->set().
The biggest thing here is sorting out static property initializers
(probably the answer there is to make them not even use arrays).
Reviewed By: @edwinsmith
Differential Revision: D972067
This diff reworks the PHP extension compat layer to be more robust by
taking steps to reconcile the difference between mainstream PHP's way and
HHVM's way of representing program values and operating on program values.
This includes the shape of the object graph in the heap (what points to
what), how refcounting is done and how "reffiness" is handled, how copy-
on-write semantics are honored, and how values are stored into arrays.
One of the core ideas here is that HHVM supports "boxing" a program value
via the RefData type and that there's a reasonably clean mapping between
PHP's object graph and HHVM's object graph (when HHVM program values are
"boxed") that maps PHP "zval" objects onto HHVM RefData objects. For the
purposes of a compat layer for PHP extensions, it makes sense to use
RefData to represent "zvals". Of course, it is unreasonable to box every
program variable in HHVM since this would hurt performance. However, we
can make things work by boxing program values lazily as needed in the
right places to ensure that Zend PHP extensions only deal with boxed
values. Along the way I also fixed a bug where we were leaking all of
the arguments that were passed to Zend PHP extension functions.
The next issue involves "reffiness". At present, HHVM RefDatas are treated
as "reffy" when their refcount is 2 or greater, while Zend PHP zvals have a
separate flag (independent of the refcount) that indicates whether they
should be treated as "reffy". Zend PHP extensions are capable of setting
two or more program variable to point to the same zval where the zval's
"reffy" flag is set to false. In such cases, the program variables share
the zval using copy-on-write semantics, where the zval must be copied
before making a modification. To make this work, we need to change RefData
somehow so that we can keep track of whether copy-on-write is needed when
the refcount is 2 or greater. Adding "reffy" flag directly poses some
challenges in terms of performance, because it means that when a value's
refcount decreases from 2 to 1 we'll need to make sure the "reffy" flag
gets cleared. I was able to avoid this by adding two flags (m_cow and m_z)
and creating a scheme that maps the 3-tuple (m_count, m_cow, m_z) to the
2-tuple (realRefcount, reffy). Under this scheme decRef continues to work
as it does today, decrementing the m_count field and calling a helper
m_count reaches zero. Another neat thing about this scheme is that m_cow is
set to 1 iff copy-on-write would be required before modifying m_tv. (NOTE:
This diff does not implement copy-on-write yet for these cases, it will be
addressed in a later diff.)
Another issue is the relationship between strings/arrays and the
zvals/RefDatas that point to them. Under Zend PHP, it is assumed that a
zval exclusively owns the string or array and that nothing else points to
the string/array. A consequence of this is that Zend PHP extensions do not
perform any copy-on-write checks with the string or array's refcount before
modifying the string/array. HHVM on the other hand supports sharing strings
and arrays between multiple RefDatas and/or program variables. Thus, we
need some way to protect against Zend PHP extensions modifying a string or
array when its refcount is 2 or greater. This is achieved by putting checks
in the right places to lazily make a copy of the string or array (when
refcount >= 2) so that Zend PHP extensions only deal with strings and
arrays with a refcount of 1.
Finally, the Zend PHP APIs for adding values to an array are a little
different. Zend PHP extensions pass a zval to the API, and the appropriate
array slot is set to point at the zval. The API does not increment the
zval's refcount; it is the caller's responsibility to do this is needed.
New APIs were added to HphpArray to address this need.
With this in place, the next things to go after would be (1) Fixing up how
the Zend compat layer deals emulating Zend PHP string macros and
operations, this may require adding a new KindOfZStr type if StringData
can't be adapted without hurting HHVM performance; (2) Adding checks in the
right places to make a copy of a RefData if m_cow is 1, I've found most the
places where this is needed and it doesn't look like these checks will
noticably hurt performance; (3) improving support for resource types and
object types defined by Zend PHP extensions and interoperability with HHVM
extension classes, HHVM resources, and user-defined pure-PHP classes.
Reviewed By: @ptarjan
Differential Revision: D966781
We need to create the catch trace before we pop the object,
since we're throwing with the marker set to before this instruction
has started. Also it needs Refs, because it can invoke the autoload
map code.
Reviewed By: @ottoni
Differential Revision: D970481
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
Drew Paroski