[Gc] Strings representation

Boehm, Hans hans_boehm@hp.com
Mon, 3 Nov 2003 08:56:05 -0800


Although it's correct, I would avoid option (3).
Among other issues, finalizers are relatively expensive.

I would guess that you would get the best performance from option (1),
but probably not by a huge amount.  Option (2) will probably win if the
application starts paging.  If this is the standard string type,
I would try to supply type information in one form or another, since
strings tend to often occupy a large fraction of the heap.

(If you really care about performance and this is the standard string
type, I would try to completely avoid pointers in most string objects, e.g.
by making the method table uncollectable for strings, and then
use option (1).  That's what gcj currently does, and I think it was
a significant win.)

Hans

> -----Original Message-----
> From: gc-admin@napali.hpl.hp.com [mailto:gc-admin@napali.hpl.hp.com]On
> Behalf Of Nicolas Cannasse
> Sent: Monday, November 03, 2003 7:15 AM
> To: gc@napali.hpl.hp.com
> Subject: [Gc] Strings representation
> 
> 
> BTW, I have one question. In a virtual machine I have a 
> string runtime value
> that contains some GC values such as a table of methods. What 
> is better
> between theses different approachs :
> 
> 1) alloc a GC block of size  header + string length , fill 
> the header and
> the string data will follow (adding maybe type info for preventing the
> string data to be scanned)
> 2) alloc a GC block of fixed size (header + 1) - in words - 
> and put in the
> additional field the address of a GC atomic allocated string
> 3) alloc a GC block of fixed size (header + 1) and put in the 
> additional
> field the address of a malloc allocated string with a 
> finalizer calling
> free.
> 
> Note : strings are immutable here, no realloc call is needed.
> 
> Nicolas Cannasse
> 
> _______________________________________________
> Gc mailing list
> Gc@linux.hpl.hp.com
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
>