[#27380] [Bug #2553] Fix pthreads slowness by eliminating unnecessary sigprocmask calls — Dan Peterson <redmine@...>
Bug #2553: Fix pthreads slowness by eliminating unnecessary sigprocmask calls
Issue #2553 has been updated by Andre Nathan.
2010/7/10 Andre Nathan <redmine@ruby-lang.org>:
[#27388] [Bug #2554] Net::FTP should not use MSG_OOB — Hongli Lai <redmine@...>
Bug #2554: Net::FTP should not use MSG_OOB
[#27393] Re: compressed pointers? — Roger Pack <rogerdpack2@...>
Martin wrote:
[#27420] closing of the stderr pipe not detected - issue in 1.9.1? — Robert Klemme <shortcutter@...>
Hi,
2010/1/5 Robert Klemme <shortcutter@googlemail.com>:
2010/1/5 Tanaka Akira <akr@fsij.org>:
[#27425] [Bug #2559] IO#write raises Errno::EINVAL instead of expected Errno::EPIPE — Hongli Lai <redmine@...>
Bug #2559: IO#write raises Errno::EINVAL instead of expected Errno::EPIPE
[#27429] [Bug #2560] IO.read not always closes the file — Vladimir Sizikov <redmine@...>
Bug #2560: IO.read not always closes the file
[#27437] [Feature #2561] 1.8.7 Patch reduces time cost of Rational operations by 50%. — Kurt Stephens <redmine@...>
Feature #2561: 1.8.7 Patch reduces time cost of Rational operations by 50%.
[#27447] [Bug #2564] [patch] re-initialize timer_thread_{lock,cond} after fork — Aliaksey Kandratsenka <redmine@...>
Bug #2564: [patch] re-initialize timer_thread_{lock,cond} after fork
[#27448] [Feature:trunk] adding hooks for better tracing — Yugui <yugui@...>
Hi,
[#27456] Re: better GC? — Roger Pack <rogerdpack2@...>
> Yes, but unfortunately it's not small at all. GC has a lot of
[#27504] C can't instantiate over existing classes? — Roger Pack <rogerdpack2@...>
Is this expected? [1.9.1]
[#27522] require behavior in 1.9 with respect to loading files with different extensions — Dirkjan Bussink <d.bussink@...>
Hi,
Hi,
[#27545] [Feature #2594] 1.8.7 Patch: Reduce time spent in gc.c is_pointer_to_heap(). — Kurt Stephens <redmine@...>
Feature #2594: 1.8.7 Patch: Reduce time spent in gc.c is_pointer_to_heap().
Issue #2594 has been updated by Kurt Stephens.
[#27551] [Bug #2595] Add crc32_combine and adler32_combine to zlib API — Aaron Patterson <redmine@...>
Bug #2595: Add crc32_combine and adler32_combine to zlib API
Hi Aaron,
On Tue, Jan 19, 2010 at 10:22:25AM +0900, NAKAMURA, Hiroshi wrote:
[#27625] [Bug #2616] unable to trap in doze — Roger Pack <redmine@...>
Bug #2616: unable to trap in doze
[#27635] [Bug #2619] Proposed method: Process.fork_supported? — Hongli Lai <redmine@...>
Bug #2619: Proposed method: Process.fork_supported?
Issue #2619 has been updated by Luis Lavena.
Hi,
On Thu, Jan 21, 2010 at 11:27 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
On Fri, Jan 22, 2010 at 1:25 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
On Fri, Jan 22, 2010 at 9:06 PM, Charles Oliver Nutter
2010/1/21 Hongli Lai <redmine@ruby-lang.org>:
On 1/21/10 5:20 AM, Tanaka Akira wrote:
2010/1/21 Hongli Lai <hongli@plan99.net>:
On Thu, Jan 21, 2010 at 10:53 AM, Tanaka Akira <akr@fsij.org> wrote:
2010/1/22 Vladimir Sizikov <vsizikov@gmail.com>:
On Thu, Jan 21, 2010 at 9:43 PM, Tanaka Akira <akr@fsij.org> wrote:
2010/1/22 Charles Oliver Nutter <headius@headius.com>:
Hi,
On Thu, Jan 21, 2010 at 12:49 PM, Vladimir Sizikov <vsizikov@gmail.com> wrote:
On 1/21/10 8:09 PM, Charles Oliver Nutter wrote:
>> I propose a method Process.fork_supported? which returns whether fork is supported on the current platform. See attached patch.
On 1/25/10 3:46 PM, Roger Pack wrote:
[#27656] A patch to rdoc — Tetsu Soh <tetsu.soh.dev@...>
Hello everyone,
[#27670] able to re-require $0 — Roger Pack <rogerdpack2@...>
Currently with 1.9.x you cannot "re-require" a file, even if you pass
Hi,
Hi,
Hi,
[#27698] [Bug #2629] ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time — Hongli Lai <redmine@...>
Bug #2629: ConditionVariable#wait(mutex, timeout) should return whether the condition was signalled, not the waited time
[#27701] [Feature #2631] Allow IO#reopen to take a block — Daniel Berger <redmine@...>
Feature #2631: Allow IO#reopen to take a block
[#27722] [Feature #2635] Unbundle rdoc — Yui NARUSE <redmine@...>
Feature #2635: Unbundle rdoc
Hi,
Issue #2635 has been updated by Yui NARUSE.
[#27748] [Bug #2636] Incorrect UTF-16 string length — Vincent Isambart <redmine@...>
Bug #2636: Incorrect UTF-16 string length
2010/1/24 Vincent Isambart <redmine@ruby-lang.org>:
What needs to be fixed here is the data, nothing else:
[#27753] [Bug #2637] unable to select for < 0.1s in windows — Roger Pack <redmine@...>
Bug #2637: unable to select for < 0.1s in windows
[#27757] [Bug #2638] ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located. — Joel Soete <redmine@...>
Bug #2638: ruby-1.9.1-p37[68] build on aix5.3 with gcc-4.2 failed to run for me because it ignores where libgcc is located.
[#27790] [Feature #2643] test/unit redefinition check of test_* method — Yusuke Endoh <redmine@...>
Feature #2643: test/unit redefinition check of test_* method
[#27791] [Bug #2644] memory over-allocation with regexp — Greg Hazel <redmine@...>
Bug #2644: memory over-allocation with regexp
Issue #2644 has been updated by Greg Hazel.
[#27794] [Bug #2647] Lack of testing for String#split — Hugh Sasse <redmine@...>
Bug #2647: Lack of testing for String#split
[#27828] [Bug #2656] Inconsistent docs for Zlib. — Hugh Sasse <redmine@...>
Bug #2656: Inconsistent docs for Zlib. [ruby-core:27692]
[#27902] Ruby 1.8.7, rb_define_method and ArgumentError: wrong number of arguments (0 for 1) — Gerardo Santana Gez Garrido <gerardo.santana@...>
I have the following method defined in a C extension:
On 1/27/10 8:55 AM, "Gerardo Santana Gez Garrido"
On Wed, Jan 27, 2010 at 11:18 AM, Eero Saynatkari
[#27912] [Bug #2669] mkmf find_executable doesn't find .bat files — Roger Pack <redmine@...>
Bug #2669: mkmf find_executable doesn't find .bat files
Issue #2669 has been updated by Luis Lavena.
[#27930] [Bug:trunk] some behavior changes of lib/csv.rb between 1.8 and 1.9 — Yusuke ENDOH <mame@...>
Hi jeg2, or anyone who knows the implementation of FasterCSV,
On Jan 28, 2010, at 10:51 AM, Yusuke ENDOH wrote:
Hi jeg2,
On Jan 28, 2010, at 11:13 AM, James Edward Gray II wrote:
Hi,
On Jan 31, 2010, at 4:40 AM, Yusuke ENDOH wrote:
[#27961] RCR: allow {select, collect, map} to accept symbol argument — Roger Pack <rogerdpack2@...>
Background.
This reply registers the suggestion by Roger to the redmine.
[ruby-core:27712] Re: [Feature #2594] 1.8.7 Patch: Reduce time spent in gc.c is_pointer_to_heap().
Roger Pack wrote:
>> I heard from the REE guys that 1.9 heaps do not grow exponentially, but remain fixed. In that case a linear O(1) probe function could help find either the min or max index, before doing a binary search.
>
Disclaimer: I probably need to read more of 1.9 gc.c.
> They do, though it allocates exponentially more of them as it needs to :)
>
> i.e. first time it allocates 16K, second time 16K*2, third time 16K*4, etc.
Why allocate exponentially at the risk of never returning anything back
to the OS?
If a program has a stable memory profile at 16k*16, but it allocates
just *one* more object, it just stole 16K*32 from the OS with almost no
possibility of ever returning it -- just for one object. Now multiply
that by 10 processes, all with the same work profile.
>
> The hope is that smaller heap chunks can be freed more readily, so it
> has a fixed size.
>
A single live object in a chunk would prevent returning the chunk back
to the malloc() pool. It's rare that malloc() returns memory back to
the OS, anyway, unless the allocation profile is LIFO-like (i.e. last
malloc()'ed, first free()'ed). Since we share the same malloc() pool
with other C code (and resizing String and Array buffers), it's very
unlikely, because malloc() suffers from the same restrictions: it cannot
return partial pages it chunked back to the OS.
I doubt that we ever get lucky enough, because
MRI gc.c is not a copying collector and other code is competing for
malloc()s. Has anybody instrumented
free_unused_heaps(rb_objspace_t *objspace) to see if it ever actually
finds anything to free() in a real program?
Those unused pages of the 16k*32 have all been dirtied by chunking them
into the free list. Depending on the OS, allocated virtual memory may
not be mapped to real (or swap) memory until it's been dirtied.
There is no benefit to allocating *anything* exponentially. In fact
it's likely that the allocation causes longer pauses over time, because
of the chunking. Any exponential allocation scheme, including
"power-of-2" malloc() implementations, wastes about 50% of its memory on
average.
> How would a probe function work with tons of 16K chunks, though?
If they are semi-contiguous, a probe would probably get close since the
chunks are all of the same size. If we allocated heap_slots via mmap()
in our own "zone", we could avoid internal fragmentation of heap_slots
by other malloc() calls.
FRAGMENTATION:
If there is a wide range of sizes in the RVALUE.as union, we would do
better by allocating heap_slots by size of the objects and segregating
free lists.
(gdb) p sizeof(struct RBasic)
$1 = 8
(gdb) p sizeof(struct RObject)
$2 = 20
(gdb) p sizeof(struct RClass)
$3 = 20
(gdb) p sizeof(struct RFloat)
$4 = 16
(gdb) p sizeof(struct RString)
$5 = 20
(gdb) p sizeof(struct RArray)
$6 = 20
(gdb) p sizeof(struct RRegexp)
$7 = 20
(gdb) p sizeof(struct RHash)
$8 = 20
(gdb) p sizeof(struct RData)
$9 = 20
(gdb) p sizeof(struct RTypedData)
$10 = 20
(gdb) p sizeof(struct RStruct)
$11 = 20
(gdb) p sizeof(struct RBignum)
$12 = 20
Thus each RFloat suffers from 25% internal internal fragmentation.
By segregating chunks by size, we could inline some of the auxiliary
structures and further reduce external fragmentation caused by
malloc()ing them:
Change:
struct RHash {
struct RBasic basic;
struct st_table *ntbl; /* possibly 0 */
int iter_lev;
VALUE ifnone;
};
TO:
struct RHash {
struct RBasic basic;
struct st_table ntbl;
int iter_lev;
VALUE ifnone;
};
to avoid malloc()ing an st_table for each RHash.
"sizeof" allocators have advantages over "power-of-2" allocators:
* less internal fragmentation,
* better locality of types (if "size" is an attribute of "type"),
* can be tuned to behave like "power-of-2" allocators above a certain
threshold.
Some Lisp systems segregate allocations by type, which localizes consed
lists, improving memory cache hits during linked list processing.
I've written a "sizeof/type"-based conservative collector, but I'd
rather invest time on getting the BDW collector working under MRI:
* it's thread-safe,
* it's been in use for more than 22 years,
* it works on almost every platform,
* in almost any program (except in MRI!)
* and is embedded in more hardware than we can probably guess.
I think BDW supports "sizeof" allocation through GC_API void *
GC_malloc_explicitly_typed(size_t size_in_bytes, GC_descr d);
The biggest impediment to hooking up a different conservative GC
is ObjectSpace.each_object. The sooner we deprecate that feature,
the sooner we can separate MRI from its allocator.
> -r
>
- KAS