[kaffe] -O4 jit3 problem

[Archie Cobbs]

Patrick Tullmann writes:
> > Yes.  The string isn't walked anymore by the time it's destroyed,
> > the char array could already be gone.
> 
> Ah, okay.  I'm also amazed that this hasn't cropped up before, and
> still refuses to crop up with the other builds of Kaffe...  Very odd.
> 
> Anyone want to come up with a worst-case test case that generates lots
> and lots of strings that all have the same hash code?
> 
> Would a better solution to the hacks in hashtab or stringCompare be to
> make the string's array of chars an explicitly allocated/deallocted
> sub-object? Then the stringDestroy method could free the char array
> and we'd avoid this whole race condition.  Strings aren't allowed to
> ever export their char-array, because that could violate their
> immutability.  Right?
> 
> Do strings sometimes share underlying char arrays?  That would make
> the explicit alloc/dealloc scheme more difficult, too.

Yes (I think).. e.g., if created using the StringBuffer class.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com