[Gc] Strings representation
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.)
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On
> Behalf Of Nicolas Cannasse
> Sent: Monday, November 03, 2003 7:15 AM
> To: firstname.lastname@example.org
> 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
> field the address of a malloc allocated string with a
> finalizer calling
> Note : strings are immutable here, no realloc call is needed.
> Nicolas Cannasse
> Gc mailing list