[#15701] Ruby 1.9.0-1 snapshot released — Yukihiro Matsumoto <matz@...>
Hi,
[#15704] Proc#curry doesn't work on func which produces func — Lin Jen-Shin <godfat@...>
Proc#curry doesn't work on function which produces function,
Hi,
>>>>> "Y" == Yusuke ENDOH <mame@tsg.ne.jp> writes:
[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>
Hi, developers,
On Sat, Mar 01, 2008 at 08:58:00PM +0900, Akinori MUSHA wrote:
Hi,
At Fri, 21 Mar 2008 23:16:54 +0900,
At Mon, 24 Mar 2008 21:39:45 +0900,
[#15709] capitalize and downcase — Trans <transfire@...>
I've always wondered why String#capitalize downcases the whole string
[#15713] Ruby String hash key overflow when converting to Fixnum. — "Chiyuan Zhang" <pluskid@...>
Hi, all! I've opened a issue at rubyforge:
[#15728] Question on build process - skipping unsupported extensions — Daniel Berger <djberg96@...>
Hi,
[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>
Hi.
Hi,
Yukihiro Matsumoto wrote:
Yukihiro Matsumoto wrote:
Hi.
Hongli Lai wrote:
Hi.
Hi,
I believe I managed to close the performance gap to only 6% slower than
Daniel DeLorme wrote:
[#15746] Am I misinterpreting the new keyword arguments to IO.foreach and friends? — Dave Thomas <dave@...>
I was expecting this to pass lines to the block:
[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>
Hello,
Hi,
Hi,
Yukihiro Matsumoto wrote:
Suraj N. Kurapati wrote:
Hi,
Nobuyoshi Nakada wrote:
Suraj N. Kurapati wrote:
Hongli Lai wrote:
[#15775] next(n), succ(n) ? — Trans <transfire@...>
Can anyone see any reason against adding an optional parameter to
[#15778] Named captures and regular captures — Dave Thomas <dave@...>
It seems that once you have a named capture in a regular expression,
[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>
Hi all,
Daniel Berger wrote:
On Wed, Mar 05, 2008 at 07:52:40AM +0900, Daniel Berger wrote:
[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>
I've been reworking JRuby's stdlib to improve performance and fix
On Sun, 2008-03-09 at 12:13 +0900, MenTaLguY wrote:
[#15837] Correct procedure for patch review? — Hongli Lai <hongli@...99.net>
Hi.
[#15855] Ruby 1.8.6 trace return line numbers wrong — "Rocky Bernstein" <rocky.bernstein@...>
Consider this program:
[#15860] Webrick directory traversal exploit on UNIX — Jos Backus <jos@...>
DSecRG Advisory #DSECRG-08-026 aka -018 describes a remote directory traversal
[#15871] Sparc architecture optimizations — Thomas Enebo <Thomas.Enebo@...>
Someone at Sun has been looking at Ruby on Sparc:
Thomas Enebo wrote:
Hello Ruby-core,
Hi,
Yukihiro Matsumoto wrote:
Prashant Srinivasan wrote:
[#15880] Ruby 1.8.6 binding value after "if" expression evaluation — "Rocky Bernstein" <rocky.bernstein@...>
Here's another trace hook weirdness that I've encountered.
Hello,
Thanks. The output you report matches what I get in 1.8.6 and suggests where
I think I've found why this is happening. The trace hook for NODE_IF is
[#15907] Range#member? semantics seem wrong — Dave Thomas <dave@...>
Range#member? has been changed so that it the start and end of the
[#15909] RARRAY_PTR — "Laurent Sansonetti" <laurent.sansonetti@...>
Hi,
[#15917] Ruby 1.9 (trunk) crashes when running RubyGems and Rake — Hongli Lai <hongli@...99.net>
Ruby 1.9 (trunk) seems to crash when running the supplied RubyGems and Rake:
Hi,
Nobuyoshi Nakada wrote:
On Mon, Mar 17, 2008 at 06:53:19PM +0900, Hongli Lai wrote:
[#15927] how to create a block with a block parameter in C? — Paul Brannan <pbrannan@...>
This works in Ruby (1.9):
>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:
[#15933] complex and rational — Dave Thomas <dave@...>
Before I start doing the documentation for the PickAxe, could I just
[#15936] Are Depreciated Methods "add_final" & "remove_final" supposed to ACTUALLY WORK? — Charles Thornton <ceo@...>
In Working on IRHG Docs for GC the following
>>>>> "C" == Charles Thornton <ceo@hawthorne-press.com> writes:
ts wrote:
[#15938] Questions on Enumerator#skip_first and Enumerable#first — "Artem Voroztsov" <artem.voroztsov@...>
I asked in ruby-talk, but did not get answer.
On Mar 18, 2008, at 6:20 AM, Artem Voroztsov wrote:
[#15975] Bugs in REXML — "Federico Builes" <federico.builes@...>
Hi,
On Mar 21, 2008, at 17:35, Federico Builes wrote:
[#15980] 1.8.6 memory leak? — "Stephen Sykes" <sdsykes@...>
Hi,
[#15983] Changing the algorithm of String#* — apeiros <apeiros@...>
Hi there
[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>
Hi,
Hi Dave,
Hi Dave,
Hi,
Hi,
Hi,
On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:
Dave Thomas wrote:
Dave Thomas wrote:
Dave Thomas wrote:
Dave,
This is all a semantic problem. Different people have different
[#16011] New ERb mode — Marc Haisenko <haisenko@...>
Hi folks,
On Tuesday 25 March 2008, Marc Haisenko wrote:
ERb already does this:
On Tuesday 25 March 2008, Jason Roelofs wrote:
On Tue, Mar 25, 2008 at 11:39 AM, Marc Haisenko <haisenko@comdasys.com> wro=
On Tuesday 25 March 2008, Jason Roelofs wrote:
[#16023] some Enumerable methods slower in 1.9 on OS X after revision 15124 — Chris Shea <cmshea@...>
All,
Hi,
Hi,
On Thu, Mar 27, 2008 at 02:26:51PM +0900, Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
[#16057] About the license of gserver.rb being "freeware"? — "XiaoLiang Liu" <liuxlsh@...>
Hello everyone,
[#16088] command_call in parse.y — Adrian Thurston <thurston@...>
Hi,
Re: Copy-on-write friendly garbage collector
Daniel DeLorme wrote: > I believe I managed to close the performance gap to only 6% slower than > the current implementation (but I must admit I have trouble getting > consistently reproducible benchmarks). The attached patch should be > added on top of the one in Matz' email. > > -- > Daniel > Great work Daniel. I don't measure the same amount of speedup that you claim in your email, but there is definitely a small speedup. I've added some further further optimizations. find_position_in_bitfield() now uses bit operators instead of division and modulo operators. This should speed things up a little more. The attached patch is created against Ruby 1.8, but it shows what I've exactly changed.
Attachments (1)
diff --git a/gc.c b/gc.c
index cb18a79..3ba5ec5 100644
--- a/gc.c
+++ b/gc.c
@@ -1142,6 +1142,7 @@ gc_sweep()
int i;
unsigned long live = 0;
unsigned long free_min = 0;
+ struct heaps_slot *heap;
for (i = 0; i < heaps_used; i++) {
free_min += heaps[i].limit;
@@ -1154,9 +1155,11 @@ gc_sweep()
/* should not reclaim nodes during compilation
if yacc's semantic stack is not allocated on machine stack */
for (i = 0; i < heaps_used; i++) {
- p = heaps[i].slot; pend = p + heaps[i].limit;
+ heap = &heaps[i];
+
+ p = heap->slot; pend = heap->slotlimit;
while (p < pend) {
- if (!rb_mark_table_contains(p) && BUILTIN_TYPE(p) == T_NODE)
+ if (!rb_mark_table_heap_contains(heap, p) && BUILTIN_TYPE(p) == T_NODE)
gc_mark((VALUE)p, 0);
p++;
}
@@ -1184,7 +1187,7 @@ gc_sweep()
obj_free((VALUE)p);
}
if (need_call_final && FL_TEST(p, FL_FINALIZE)) {
- rb_mark_table_add(p); /* remain marked */
+ rb_mark_table_heap_add(heap, p); /* remain marked */
p->as.free.next = final_list;
final_list = p;
}
diff --git a/marktable.c b/marktable.c
index 7424633..412616f 100644
--- a/marktable.c
+++ b/marktable.c
@@ -34,10 +34,26 @@ find_position_in_bitfield(struct heaps_slot *hs, RVALUE *object,
unsigned int *bitfield_index, unsigned int *bitfield_offset)
{
unsigned int index;
-
index = object - hs->slot;
- *bitfield_index = index / (sizeof(int) * 8);
- *bitfield_offset = index % (sizeof(int) * 8);
+
+ /*
+ * We use bit operators to calculate the position in the bit field, whenever possible.
+ * This only works if sizeof(int) is a multiple of 2, but I don't know of any platform
+ * on which that is not true.
+ *
+ * The INT_BITS_LOG macro's value must be equal to the base 2 logarithm of sizeof(int).
+ */
+ #ifdef __i386__
+ #define INT_BITS_LOG 5
+ #endif
+
+ #ifdef INT_BITS_LOG
+ *bitfield_index = index >> INT_BITS_LOG;
+ *bitfield_offset = index & ((1 << INT_BITS_LOG) - 1);
+ #else
+ *bitfield_index = index / (sizeof(int) * 8);
+ *bitfield_offset = index % (sizeof(int) * 8);
+ #endif
}
@@ -81,6 +97,14 @@ rb_mark_table_add(RVALUE *object)
}
}
+static inline void
+rb_mark_table_heap_add(struct heaps_slot *hs, RVALUE *object)
+{
+ unsigned int bitfield_index, bitfield_offset;
+ find_position_in_bitfield(hs, object, &bitfield_index, &bitfield_offset);
+ hs->marks[bitfield_index] |= (1 << bitfield_offset);
+}
+
static inline int
rb_mark_table_contains(RVALUE *object)
{