Age | Commit message (Collapse) | Author |
|
Seen symptom: Hipe compiled code with <<C/utf8, ...>> = Bin does sometimes
not match even though Bin contains a valid utf8 character. There might be
other possible binary matching symptoms, as the problem is not utf8
specific.
Problem: A writable binary was not "emasculated" when the matching started
(as it should) by the hipe compiled code.
Fix: Add a new primop emasculate_binary(Bin) that is called when
a matchstate is created.
ToDo: There are probably room for optimization. For example only call
emasculate_binary if ProcBin.flags is set.
|
|
The hipe_mfa_info_table lock is currently a mutex, causing
unnecessary contention and serialization of lookups for
apply-like constructs.
- change the lock from a mutex to an rwmutex
- split hipe_get_na_nofail_locked into a "try" path which
only needs a read lock, and a "slow" path which requires
a write lock
- reimplement hipe_get_na_nofail (used by apply ops etc) to
first call the "try" path with a read lock, and if that
fails the "slow" path with a write lock
- reimplement hipe_get_na_nofail_locked (used by maintenance
code) to call the "try" path and then optionally the "slow"
path, but without taking locks since its caller already has
the write lock
- adjust remaining lock ops to take/release full write lock
- use _rwlocked as suffix on functions requiring a write lock
- change hipe_mfa_get_trampoline to call get_locked not put_locked,
allowing it to take a read lock instead of a write lock
- change hipe_find_mfa_from_ra() to only take a read lock
|
|
OS X Mavericks builds result in a number of warnings about finite() being
deprecated, like these:
beam/erl_arith.c:451:7: warning: 'finite' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations]
ERTS_FP_ERROR(p, f1.fd, goto badarith);
^
sys/unix/erl_unix_sys.h:319:33: note: expanded from macro 'ERTS_FP_ERROR'
^
sys/unix/erl_unix_sys.h:244:51: note: expanded from macro '__ERTS_FP_ERROR'
^
/usr/include/math.h:718:12: note: 'finite' has been explicitly marked deprecated here
extern int finite(double) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA, __IPHONE_NA);
Add checks to use isfinite() instead of finite() where available. Verified
on OS X Mavericks 10.9.5 and Ubuntu 12.04.
|
|
This commit is a preparation for eliminating a race condition
loading the native code for modules whose BEAM code has already
been loaded. Here we introduce two new BIFs so that looking up
a fun entry is separate from setting the native address in the
fun entry.
|
|
|
|
In order to avoid an ummatched return warning in erts and make the code
more sane, the return value of the bif was changed from [] to 'ok'.
(Probably more hipe_bifs need such changes but they will have to wait.)
While at it, the code of various functions in hipe_unified_loader was
shortened by using lists:foreach/1 instead of explicit recursion.
|
|
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]>
|
|
|