Request for review (L): 6797305: Add LoadUB and LoadUI opcode class

[Ulf Zibis]

Am 06.03.2009 14:06, Christian Thalinger schrieb:
> On Fri, 2009-03-06 at 13:28 +0100, Ulf Zibis wrote:
>   
>> Hi Christian,
>>
>> just to be sure, if following is included in your fix:
>>
>> What's about:
>>     char c = (char)(b & 0xFF)
>>     char c = (char)(i & 0xFF)
>> After optimization, it should be fast as or faster as
>>     char c = (char)b
>> Goal: determination, if b is positive, becomes superfluous, so we could use { char c = (char)(i & 0xFF) } in any case without speed loss.
>>
>> Also consider:
>>     char c = (char)(i & 0xFFFF)
>>     
>
> Good point.  This change only includes optimizations for array load
> operations.  I will cover cases like above in a new CR (change request).
>
>   
>>     char c = (char)(intarray[i] & 0xFFFF)
>>     
>
> Another good point.  The current load optimizations only cover widening,
> but no shortening.  Looks like another CR.
>
> Please feel free to send me some of your common use cases.
>   

use cases:

https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/AsciiShortMapDecoder.java?rev=531&view=markup
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/AsciiDirtyShortMapDecoder.java?rev=571&view=markup

    public char decode(final byte inByte) throws 
UnmappableCharacterException, MalformedInputException {
        if (inByte >= 0)
            return (char)inByte;
        if (inByte >= b2cMapLimit)
            return (char)(inByte & 0xFF);
        return b2cMap[inByte & 0xFF];
    }

could be truncated to:

    public char decode(final byte inByte) throws 
UnmappableCharacterException, MalformedInputException {
        if (inByte >= b2cMapLimit)
            return (char)(inByte & 0xFF);
        return b2cMap[inByte & 0xFF];
    }


For the last case make a search for "& 0xFFFF" and "&0xFFFF" on 
/src/share/classes/, I've found 289 matches in 84 files.
Not to forget: "0xFFFF &" and "0xFFFF&" or "0xFFFFFFFF", "255", "65535" 
and "4294967295" etc...

Generally I think, it could be good idea, to scan hole JDK for places, 
where the LoadUB, LoadUI, etc. opcode classes come to acount, and throw 
out all special java-side optimizations, when fix of those CRs are 
submitted.

-Ulf