The codebase had several namespace-level static data definitions and function definitions. Using namespace-level "static" in a .h file is near-always a bad idea, as follows:
- for simple types, static is implied. Example: "const int x = 42;" is the same as "static const int x = 42;"
- for aggregate types, static linkage implies that a copy of the aggregate will appear in every compilation unit that includes the header.
- for functions, static means the function will have a separate body generated in each compilation unit including the header.
- in several places functions were defined 'static inline', which is just as bad. 'inline' is just a hint which means the function may end up having a body (and actually more due to 'static').
True, gnu's linker has means to remove duplicate definition, but that's not always guaranteed or possible (think e.g. static functions that define static data inside, ouch). So static is useless at best and pernicious at worst. We should never, ever use static at namespace level in headers. I will create a bootcamp task for a lint rule.
I expected the performance to be neutral after the change, but in fact there's a significant drop in instruction count and therefore a measurable reduction in CPU time: https://our.intern.facebook.com/intern/perflab/details.php?eq_id=431903
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
This is a near-straight translation of gen_ext_hhvm.php into C++. The
main goal of this change is to break the bootstrap cycle in the build
process: we have to run PHP scripts to build our PHP interpreter. This
isn't so bad for us internally, but in the open-source build, it's
philosophically lame to depend on an external PHP interpreter (i.e.
Zend) to build HHVM. To get around this, we have to check in the
generated ext_hhvm files: no good.
There's nothing particularly sophisticated in this program; it's just a
bunch of grunt work. I took the opportunity to make a few improvements
to the generated code -- there was some int-width confusion, and a bunch of
duplicated code to transfer return values to the right place.
Added sha224 algo (derivative of sha256)
Added fnv132, fnv1a32, fnv164, fnv1a64 algos
Fixed tiger* finalization (endianess was backwards)
I fixed the endianness of tiger*,* and added Zend's
unit tests, but I forgot to update these tests.
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.
Andrei Alexandrescu