[#27003] [Bug #2422] splat operator fails on array of 1 element — Raul Parolari <redmine@...>

Bug #2422: splat operator fails on array of 1 element

12 messages 2009/12/02

[#27025] [Backport #2431] StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n" — Hiroshi NAKAMURA <redmine@...>

Backport #2431: StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n"

8 messages 2009/12/04

[#27086] [Feature #2454] OpenSSL has no maintainer — Yui NARUSE <redmine@...>

Feature #2454: OpenSSL has no maintainer

16 messages 2009/12/07

[#27120] #to_enum ignores block? — Roger Pack <rogerdpack@...>

Is #to_enum ignoring its block expected?

11 messages 2009/12/09

[#27135] better GC? — Roger Pack <rogerdpack@...>

Could I put in a small plea for a better GC?

56 messages 2009/12/10
[#27136] Re: better GC? — Yukihiro Matsumoto <matz@...> 2009/12/11

Hi,

[#27476] Re: better GC? — Paul Brannan <pbrannan@...> 2010/01/07

On Fri, Dec 11, 2009 at 09:07:16AM +0900, Yukihiro Matsumoto wrote:

[#27477] Re: better GC? — Eero Saynatkari <ruby-ml@...> 2010/01/07

Excerpts from Paul Brannan's message of Thu Jan 07 21:53:34 +0200 2010:

[#27563] Re: better GC? — Brent Roman <brent@...> 2010/01/12

[#27199] [Backport #2488] thread usage can result in bad HANDLE — Roger Pack <redmine@...>

Backport #2488: thread usage can result in bad HANDLE

12 messages 2009/12/16

[#27286] [Bug #2515] Array#select! — Roger Pack <redmine@...>

Bug #2515: Array#select!

17 messages 2009/12/22

[#27327] [Bug #2531] Ruby 1.8.7-p248 fails to cross-compile same version — Luis Lavena <redmine@...>

Bug #2531: Ruby 1.8.7-p248 fails to cross-compile same version

9 messages 2009/12/25

[#27360] [Feature #2542] URI lib should be updated to RFC 39886 — Marc-Andre Lafortune <redmine@...>

Feature #2542: URI lib should be updated to RFC 39886

15 messages 2009/12/31

[ruby-core:27255] Re: compressed pointers?

From: "Martin J. Dst" <duerst@...>
Date: 2009-12-21 02:55:17 UTC
List: ruby-core #27255
Looking at the wiki page at 
http://wikis.sun.com/display/HotSpotInternals/CompressedOops, what they 
do is essentially to shift pointer values right by three bits to save 
them, and shift them right by three bits again to use them. This means 
that they can address 8 times the space addressable by a 32-bit machine, 
i.e. 32GB. It works because the three lowest bits of a pointer are zero, 
if that pointer points to an object or a (64bit) int or so. It doesn't 
work for pointing into strings,... where you need per-byte precision. 
That's why the proposal talks about OOP, "ordinary object pointers".

For Ruby, there are (at least) the following two problems:
1) Object pointers in Ruby (MRI/YARV) are overlaid with integers (and 
some other values, such as true/false, and I think symbols). The 
distinction is made by using the lowest two bits, which are 00 for 
pointers and something else for immediate values.
2) The data record for a (non-immediate) Ruby object is 5 words (read 
object pointers) in size. These five words are used for different 
purposes depending on the actual object involved. In the case of a 
String, some of them point to actual string data, they therefore cannot 
be compressed.

So overall, it looks rather improbable for Ruby to compress pointers in 
the near future.

Regards,    Martin.


On 2009/12/17 8:41, Roger Pack wrote:
> I have seen that Ruby on 64-bit takes about twice as much RAM as it
> does on 32-bit machines.
>
> I also learned recently that Java with their new version 7 has some
> optimizations to "compress" 64 bit pointers somewhat, so that they use
> less space. [1]
> I wonder if something like this could be used in ruby core.
> Opinions?
> -r
> [1] http://openjdk.java.net/projects/jdk7/features/ ("compressed 64
> bit pointers")
>
>

-- 
#-# Martin J. Dst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

In This Thread

Prev Next