The line table is a shorter version of the source location table and is needed for run time behavior beyond on-line debugging. When a unit is read from a repo, the line table is converted to a pseudo source location table, which is then converted back to a line table when the unit emitter creates the unit. This line table to source location table to line table conversion seems silly in itself. It also does not round trip faithfully, with the result that code that depends on the line table will behave differently the first time than the second time. This may have be the source of flaky tests in the past. Right now, the debugger's small step flow test fails if run a second time.
This diff gets rid of the conversion and directly propagates the line table from the repo to the unit.
Reviewed By: @mikemag
Differential Revision: D969062
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
Unit::getOffsetRange(Offset pc, OffsetRange& range) did two SQL queries to the byte code repository in order to map a PC (offset) to a range of offsets that provide all of the bytecode operations that correspond to a single source statement. The information needed for this map is already recorded in the m_lineTable field of the Unit, so there is no need for a SQL query.
Reviewed By: @mikemag
Differential Revision: D966164
Generically, this diff treats an uninit_null constant
as undefined. Currently, this only occurs with k_SID.
Closes#190
Reviewed By: @markw65
Differential Revision: D960974
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
There was a race in defClass that could result in
a defClass on a different thread succeeding, before the original
had added the new Class to the NamedEntity's clsList. That could
result in a crash in compactMergeInfo.
Differential Revision: D949580
If redoHoistable is set, at least one defClass failed,
so we can't compact the unit.
This should prevent crashes - but something must have gone wrong
to get into this state. An AttrUnique class should never fail
to be defined.
Differential Revision: D946531
Pulling the trigger; it's unused post-tx64. This diff preserves the
ability to mark units as merge-only when the pseudomain only contains
assignments to known globals. When the unit is being merged, the set
operation goes directly to the global varenv instead of through the
targetcache (GlobalCache stored pointers into the global varenv's
NameValueTable).
This function used memcpy on TypedValues where it doesn't
know the storage location, which is dangerous if the target lives in a
HphpArray (or anything else that uses m_aux). It also just seems like
it's now an unnecessary/redundant entry point in the typed value API.
Several uses of it are on things that can't be KindOfRef anyway (I
fixed constants, but where I wasn't sure I used tvToCell first).
Pulling the trigger; it's unused post-tx64. This diff preserves the
ability to mark units as merge-only when the pseudomain only contains
assignments to known globals. When the unit is being merged, the set
operation goes directly to the global varenv instead of through the
targetcache (GlobalCache stored pointers into the global varenv's
NameValueTable).
Supersedes D891179 -- I was overly aggressive in that one.
For PhpFiles, there was a mixed management system, where references from
translated code were held until the code was made unreachable, while
references from interpreted code were held for the duration of the
current request. Under the new scheme, PhpFiles are always treadmilled.
They are owned by the FileRepository, and so need to be ref-counted
because the FileRepository can have the same PhpFile under multiple
paths. But we don't ref-count the *uses* of PhpFiles anymore.
Classes still need to be ref-counted, but as soon as their Unit
goes away, most of their internals can be freed. We just need to
hold onto them if derived classes are referencing them. Even in
that case, the next time we try to instantiate the derived class,
we can kill any that reference this Class.
There were also lots of holes where references were not dropped,
or owned data structures were not destroyed. eg a Class's methods
were not destroyed when the Class was destroyed; there were
several paths where an entry was erased from the file map, but the
corresponding PhpFile was not decRef'd - or worse, a null entry
was left in the map (something we had asserts to check for).
This tries to make the handling more consistent.
Turns out I need to use tvSet with temporaries. Also removes
unused tvSetObject*, and replaces some tvSetNull* callsites with using
make_tv temporaries.
This diff removes the Marker opcode, replacing it with a BCMarker
struct in each IRInstruction. This gives us fewer redundant lines in IRTrace
dumps and allows for more straightforward control of which IRInstructions are
associated with which bytecodes. I took this opportunity to do some more
cleanup of ir dumps as well, and it's now possible to interpOne every codegen
punt.
Replace NameDef with a new struct of runtime-resolved typedef
information. This needs to include more than Class* or Typedef*,
because we might have nullable type aliases, or a non-nullable alias
to a nullable typedef, or vice versa. Switch to the new
TypeAnnotation stuff in TypedefStatement instead of just strings so
support for this isn't weird (shapes are outside of this for now
though---see the hack in parser.cpp). Also fixes support for type
aliases to mixed.
The AtomicHashMap constructor seems to be causing
Unit::GetNamedEntity to take forever to compile in the opt build, so I
moved the initialization out of that function and marked it #pragma
GCC optimize ("O0") to prevent whatever crazy optimization is freaking
gcc out.
Because stronger types are better types, and this will make
future refactoring easier. I considered trying to purge the Opcode
type from the codebase too but that would be a much bigger project.
Instead of doing name-based checks, using a flag in the runtime seems better. I tried to have a flag on the FuncEmitter that was set when you made these weird functions, but there was a few situations that needed to do name-based checks
* .hhas files have no control over anything but the name
* the parser would have to pass the info through the AST to the emitter
Instead I opted for the simpler approach for now until we want to solve those.
I was looking at a jemalloc profile of HPHP ram and noticed
250 MB of RAM allocated from UnitEmitter::UnitEmitter. This
doesn't make sense since the memory is released on destruction.
I think that we're calling setBc which leaks the memory
The value of m_feMap is never used. Keys are used to assert when there
is an attempt to define a function with already existing name. It does
this job poorly because it is not an authoritative source of existing
function names. When the top-level function is defined, setCached() is
called, which already checks for duplicates, so let's rely on it.
This reverts commit 2e9677b7c3f37e9627b9cbc9a6ddec82a10e7215.
Third time is the charm. I hid it from reflection, but I missed `get_class_methods`.
The diff betweenn this and what was reverted is https://phabricator.fb.com/P2217891 and then I did https://phabricator.fb.com/P2217904 because it looked like it should be done.
The problem was a few:
* All constant declarations were wrapped in a statement list. The merge-only check was allowing top-level `define()`s but not top level statement lists. I unwrapped them. I have no idea why it was done. Probalby just cargo cult programming.
* When converting a UnitEmitter to a Unit we only allowed constants in RepoAuthoritative mode and not systemlib mode.
* Systemlib constants weren't being set as UnitMergeKindPersistentDefine
* UnitMergeKindPersistentDefine constants weren't being marked mergeOnly when pulling out of a repro
Throws the aliased class into a target cache slot for the new
name. Handles errors when you try to re-alias a class, but doesn't
restrict a few other cases zend does:
- If you implement an interface twice, zend complains (one of the
alias tests checks this). I tried turning it on, but we violate
it in systemlib currently so I left it off.
- class_alias_014.php does some namespace stuff I don't quite grok.
(@ptarjan let me know what to do if it's easy).
- inter_007.php uses class_alias, but is testing a warning that
happens even with out it. (We don't raise this warning.)
- zend raises a warning if you try to class_alias a non-user-defined
class; I left this out.
It's better to have some checks than none. The only checks
failing in systemlib are iterator lifetime things, which it seems like
we're not about to fix. Run the verifier on systemlib but only in
debug builds.
runtime/eval is a relic of a bygone era. As long as we're cleaning up
our directory structure, let's move FileRepository (the only remaining
thing in runtime/eval/runtime) to where it makes sense.
runtime/eval still contains the debugger, which would probably make more
sense as runtime/debugger, but I don't want to throw a wrench in the
works for @mikemag and @hermanv unnecessarily.
I was going to #include translator.h in a header I had for
talking to the region selector thing and decided to just get this over
with instead. (It shouldn't need to #include that.) Found a few
other unused things to remove while at it.
This was barely a demonstrable win in sandbox mode when I first wrote
it and it's not even used in hhir. It's probably been bitrotting and is causing
crashes for some people. Time to say goodbye.
Herman Venter