[kaffe] -O4 jit3 problem

[Patrick Tullmann]

> 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.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
   Sleep required by the average person is just five more minutes.