Anouncing the (somewhat broken) E v0.7.1 release

[Bill Frantz]

At 04:54 PM 11/10/98 -0800, Mark S. Miller wrote:
>At 02:08 PM 11/10/98 , Chip Morningstar wrote:
>>>* At no performance cost, ELib no longer breaks when run under jvm that
>>>don't correctly intern literal strings.  Likewise, it's also tolerant of
>>>being handed non-interned verbs.
>>
>>How can you possibly do this at no performance cost.
>>Enquiring minds want to know.
>
>
>[a] Oops, I spoke too simply.
>
>It's only no cost in the by far common case case -- when an interned verb
>is provided and the method is found.  It also isn't quite *no* cost even in
>this case, but it could be if the code were arranged differently.  As it
>is, even in the normal case I have an extra null test.
>
>Old code:
>
>        Object m = myMethods.get(verb, null);
>
>New code:
>
>        Object m = myMethods.get(verb, null);
>        if (m == null) {
>            verb = verb.intern();
>            m = myMethods.get(verb, null);
>        }
>
>Since m is later effectively tested for null anyway, if the code were
>reorganized, we could have one null test do both jobs in the normal case,
>resulting in no cost in this case.
>
>In any case, I'm going to use the same trick for E scopes as well.

While I think the trick is worth while, I think the costs may be higher
than expected.  What I see happening is:

(1) Client with un-interned string (JVM bug probably) does E.send
(2) The above code interns the string and saves the interned value, does
the invocation etc.
(3) The client uses the un-interned string again to do the E.send and we go
thru the exercise all over again.