I opened this can of worms while trying to devirtualize ObjectData, and
trying to understand how objects get destructed. It turned out that
every ObjectData and ResourceData subclass was defining its own operator
delete via several layers of macros, and they all did the same thing.
I deleted the one for ObjectData and let everything be handled by the
definition of operator delete in ObjectData itself. ResourceData makes
this harder: given a ResourceData*, we don't have quite enough
information handy to know how big its dynamic type is, so we're still
using the macro-generated override in every ResourceData derived class.
This more closely reflects reality, since ResourceData and ObjectData
are separate class hierarchies now.
Differential Revision: D943826
Privatize several public functions, remove some redundant
functions, make some things non-members (appendJSONEscape), remove
DECLARE_BOOST_TYPES, and document contracts; also some gratuitous
style changes. I was initially planning to make it include the null
in its capacity, but since capacity is not exposed anywhere I think
it's fine as is. (And eventually we don't want to require the null
when handing off to String---only when people call data()---but that
is a separate project.)
Differential Revision: D931746
- Eliminate Util::safe_strerror and use folly::errnoStr instead since the former is less safe as it doesn't preserve errno
Differential Revision: D920282
Incrementally renaming foo_bar.* to foo-bar.*. runtime/vm
is nearly done, getting started on runtime/base. This does
a dozen or so files, will do more in separate diffs.
Differential Revision: D910489
In HHVM (and HPHPc before it) 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 prepares the code base for a new KindOfResource type by adding a
new "Resource" smart pointer type (currently a typedef for the Object smart
pointer type) and it updates the C++ code and the idl files appropriately.
This diff is essentially a cosmetic change and should not impact run time
behavior. In the next diff (part 2) we'll actually add a new KindOfResource
type, detach ResourceData from the ObjectData inheritence hierarchy, and
provide a real implementation for the Resource smart pointer type (instead
of just aliasing the Object smart pointer type).
C++11 cleanup (clean up easy enums)
This is for runtime/base/... and ended up touching a lot of files
because it turns out we have a lot of reasonably behaved enums.
A recent diff started (correctly) passing the environment
through to child processes. It turns out our LightProcess implementation
can't handle environment variables with new lines in them, so (for now)
strip out any such variables.
obsoletes D825704? populate our env array from environ,
then overlay local changes that were made to m_envs.
I didn't make this conditional on CLI but could if that is desirable.
I didn't tackle the allocate-after-fork issue that @jdelong raised in D825704
I was learning from @jdelong and he said that you should use
double quotes for local includes and angle brackets for library
includes. I asked why our code was the way it was, and he said he wanted
to clean it up. I beat him to it :)
Conflicts:
hphp/runtime/base/server/admin_request_handler.cpp
hphp/runtime/vm/named_entity.h
Some head scratching until I realized that my `putenv()` calls
in my PHP script weren't actually changing the environment for subsequent
`proc_open()` calls.
What I'd like this diff to do (and I fully expect that I'm violating some
referencing rules in hhvm) is to fall back to using our current view of
the environment as maintained in the execution context in the case that
proc_open is not explicitly passed an environment array.
I think I've even added a test to prove that this works, but I haven't
read the manual and fbmake runtests takes too long, so I'm just going
ahead to submit this diff.
This gets rid of the (litstr) StringData and StackStringData
constructors, but keeps String(litstr). Also rename all
the instances of AttachLiteral to CopyString, since they now
mean the same thing.
unserialize() and call_user_func_array() were straightforward. They were
called from all over the runtime, but I renamed those implementations
and codemodded the runtime.
The is_* functions were only ever being called by the CVarRef signature,
so I deleted all the other ones (same for f_gettype). Only some of the
is_* functions were being called from the runtime, so I made inline
versions of those without the f_ prefix.
Post-hphpc, declaring builtins as inline is useless, which obviates the
need for this layer.
This doesn't fully delete the file, because I wanted to keep mindless
parts and use-your-brain parts separate. This is the mindless part. The
remaining functions in noinline.cpp are no-inline wrappers around
(a) a function that isn't defined in an extension, call_user_func_array,
and (b) calling polymorphic is_* functions, which can probably mostly go
away now. But I wanted to exercise more care around those, so they'll
come in a followup diff.
Per @mwilliams' suggestion, this is the first stage in a staggered approach to replacing int64 with int64_t. More precisely I inserted "typedef ::int64_t int64;" in util/base.h and dealt with the consequences.
This change is mostly for FB internal organizational reasons.
Building is not effected beyond the fact that the target now
lands in hphp/hhvm/hhvm rather than src/hhvm/hhvm.
Jordan DeLong