| Age | Commit message (Collapse) | Author |
|---|
|
* pg/fix-freebsd-dualcore-detection:
Fix bug in FreeBSD topology detection code
OTP-9453
|
|
|
|
|
|
Conflicts:
erts/emulator/beam/erl_printf_term.c
|
|
* sverker/erts_printf-halfword:
erts_printf %be to print integers of size Eterm
Fix use of type BeamInstr in hipe_debug.c
Conflicts:
erts/emulator/hipe/hipe_debug.c
|
|
Existing %bp to print pointer size integers does not work in halfword
emulator to print Eterm size integers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The atomic memory operations interface used the 'long' type and assumed that
it was of the same size as 'void *'. This is true on most platforms, however,
not on Windows 64.
|
|
* rickard/rwmutex-bug/OTP-8925:
Fix erroneous assertion
|
|
|
|
* rickard/rwmutex-bug/OTP-8925:
Use correct argument types on rwlock_wake_set_flags()
|
|
|
|
* rickard/rwmutex-bug/OTP-8925:
Miscellaneous rwmutex bug fixes and improvements
Don't use more reader groups than schedulers
New test suite containing stress tests of the rwmutex implementation
Conflicts:
erts/emulator/beam/erl_init.c
|
|
The ERTS internal rwlock implementation could get
into an inconsistent state. This bug was very seldom
triggered, but could be during heavy contention. The
bug was introduced in R14B (erts-5.8.1).
The bug was most likely to be triggered when using the
read_concurrency option on an ETS table that
was frequently accessed from multiple processes doing
lots of writes and reads. That is, in a situation where
you typically don't want to use the read_concurrency
option in the first place.
|
|
* pg/freebsd-cpu-affinity-and-topology:
Add support for CPU affinity & topology detection on FreeBSD 8
OTP-8939
|
|
|
|
|
|
A bug causing a deadlock in the reader optimized rwlock
implementation has been fixed. This bug appeared in
commit 59ee2a593090e7d53c97ceba63cbd300d1b9657e, i.e.,
it has not been seen in any released versions.
|
|
|
|
|
|
Spin wait on most ethread rwlocks used by the runtime system was
unintentionally disabled during development. Spin wait has now been enabled
again. This bug appeared in commit 59ee2a593090e7d53c97ceba63cbd300d1b9657e,
i.e., it has not been seen in any released versions.
|
|
|
|
The CPU topology is now automatically detected on Windows
systems with less than 33 logical processors. The runtime system
will now, also on Windows, by default bind schedulers to logical
processors using the 'default_bind' bind type if the amount of
schedulers is at least equal to the amount of logical processors
configured, binding of schedulers is supported, and a CPU topology
is available at startup.
|
|
Calling erlang:system_info/1 with the new argument 'update_cpu_info'
will make the runtime system reread and update the internally stored
CPU information. For more information see the documentation of
erlang:system_info(update_cpu_info).
|
|
Large parts of the ethread library have been rewritten. The
ethread library is an Erlang runtime system internal, portable
thread library used by the runtime system itself.
Most notable improvement is a reader optimized rwlock
implementation which dramatically improve the performance of
read-lock/read-unlock operations on multi processor systems by
avoiding ping-ponging of the rwlock cache lines. The reader
optimized rwlock implementation is used by miscellaneous
rwlocks in the runtime system that are known to be read-locked
frequently, and can be enabled on ETS tables by passing the
`{read_concurrency, true}' option upon table creation. See the
documentation of `ets:new/2' for more information.
The ethread library can now also use the libatomic_ops library
for atomic memory accesses. This makes it possible for the
Erlang runtime system to utilize optimized atomic operations
on more platforms than before. Use the
`--with-libatomic_ops=PATH' configure command line argument
when specifying where the libatomic_ops installation is
located. The libatomic_ops library can be downloaded from:
http://www.hpl.hp.com/research/linux/atomic_ops/
The changed API of the ethread library has also caused
modifications in the Erlang runtime system. Preparations for
the to come "delayed deallocation" feature has also been done
since it depends on the ethread library.
Note: When building for x86, the ethread library will now use
instructions that first appeared on the pentium 4 processor. If
you want the runtime system to be compatible with older
processors (back to 486) you need to pass the
`--enable-ethread-pre-pentium4-compatibility' configure command
line argument when configuring the system.
|
|
ethr_rwmutex_tryrlock() acquired and refused to acquire a lock with
inverted logic. The lock was however never acquired in a thread unsafe
manner. (Thanks to JR Zhang for noting this issue)
|
|
Writer preferred pthread read/write locks has been enabled on Linux.
|
|
Support for using gcc's built-in functions for atomic memory access has
been added. This functionallity will be used if available and no other
native atomic implementation in ERTS is available.
|
|
The runtime system crashed if fewer logical processors were found than
reported by sysconf( SC_NPROCESSORS_CONF).
|
|
environment after a number of bugs are fixed and some features
are added in the documentation build process.
- The arity calculation is updated.
- The module prefix used in the function names for bif's are
removed in the generated links so the links will look like
http://www.erlang.org/doc/man/erlang.html#append_element-2
instead of
http://www.erlang.org/doc/man/erlang.html#erlang:append_element-2
- Enhanced the menu positioning in the html documentation when a
new page is loaded.
- A number of corrections in the generation of man pages (thanks
to Sergei Golovan)
- Moved some man pages to more apropriate sections, pages in
section 4 moved to 5 and pages in 6 moved to 7.
- The legal notice is taken from the xml book file so OTP's
build process can be used for non OTP applications.
|
|
checking if CC equaled gcc. That is, the makefiles failed to
detect gcc C compilers with other command line names than gcc.
`configure' now substitute GCC into the makefiles. If CC is a gcc
C compiler, GCC will have the value yes. (Thanks to
Jean-S�bastien P�dron)
|
|
|
