| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
erts/preloaded/ebin/init.beam
|
|
This is a workaround for init:restart.
The root problem is that delete/purge_module does not
clean up internal hipe bookkeeping (hipe_mfa_info's)
properly.
Symptom: Execution of deallocated beam code.
|
|
Tuple funs were deprecated in R15B (in commit a4029940e309518f5500).
|
|
* maint:
Remove stale code for hybrid heap and incremental GC
Remove the hipe_bifs:show_message_area/0 BIF
Remove support for erlang:system_info(global_heaps_size)
Remove the erlang:garbage_collect_message_area/0 BIF
Remove workarounds for hybrid and shared heaps in test suites
Conflicts:
erts/doc/src/erlang.xml
erts/emulator/beam/erl_message.c
erts/emulator/beam/erl_process.c
erts/emulator/beam/erl_process.h
erts/emulator/hipe/hipe_bif2.tab
lib/hipe/cerl/erl_bif_types.erl
|
|
The hybrid heap emulator was last working in the non-SMP R11B
run-time system. When the constant pools were introduced in R12B,
the hybrid heap emulator was not updated to handle them.
At this point, the harm from reduced readability of the code is
greater than any potential usefulness of keeping the code.
|
|
|
|
|
|
|
|
|
|
Staging is a better and more general name as does not necessary need
to involve code loading (can be deletion, tracing, etc).
|
|
|
|
|
|
Still blocking code loading
|
|
|
|
|
|
|
|
|
|
Hipe constants used to be allocated within a single, fixed-size pool for
interaction with the garbage collector. However, the garbage collector
no longer depends on constants being allocated within a single pool, and
the fixed size of the pool both meant unnecessary allocations on most
deployments and crashes on deployments requiring more constants.
The code was simplified to directly invoke erts_alloc.
Debugging and undocumented function hipe_bifs:show_literals/0 was
removed (it returned true and output text to the console), and
debugging and undocumented function hipe_bifs:constants_size/0 was
rewritten with a global to count the size of allocated constants.
|
|
It's been reported that HiPE-enabled Erlang VMs running on BSD
systems sometimes generate messages like
Yikes! erts_alloc() returned misaligned address 0x8016a512c
These originate from hipe_bif0.c:hipe_bifs_alloc_data_2().
A native code module has an associated data area of some
size and alignment. In the case where the size is zero,
the alignment is irrelevant, but the allocation BIF checks
it anyway. The warning then triggers on systems where
malloc(0) returns blocks with less alignment than we
(erroneously) expected.
The fix is to simply skip the allocation in this case and
return NULL. The loader won't actually use the address in
this case so that's safe. This is also an optimization since
it avoids allocating memory that cannot be used, and it avoids
fragmenting the system heap with useless tiny blocks.
A second problem is that the warning message failed to
identify its origin. Fixed by prefixing the message by
the BIF's name rather than the silly Yikes! string.
Tested and confirmed to solve the original reporter's problem.
|
|
|
|
* mp/hipe-smp-fixes:
work around hipe_mfa_info_table lock omission
fix hipe loader SMP non-atomicity error
OTP-8397 The loading of native code was not properly atomic in the SMP
emulator, which could cause crashes. Also a per-MFA information
table for the native code has now been protected with a lock
since it turns that it could be accessed concurrently in the SMP
emulator. (Thanks to Mikael Pettersson.)
|
|
HiPE maintains per-MFA information such as native code entry
point in a table. This table was thought to be read-only at
runtime, except when the loader populates it, so it employed
no locking. That turned out to be incorrect: if there is an
apply of a previously unseen MFA, a native code stub for that
MFA is created and recorded in the table, causing it to grow.
Work around this for now by slapping a mutex around accesses
to that table.
Signed-off-by: Mikael Pettersson <[email protected]>
|
|
|
