Name: bsC130419 Date: 06/05/2001
Applicable to all jdks.
Currently jvm does not provide explicit way to handle overflow on integer
arithmetics. There is an easy way to detect this in most hardware, but
overflow flags are not exposed at bytecode layer. There are groups of
applications which need to either detect overflow (and react accordingly) or
perform saturated arithmetics (mostly graphics apps).
There are ways to work around that (see below at workaround section), but they
are both slow and sometimes tricky. With simple change to bytecode it could be
made more explicit.
I would propose to add two modifier bytecodes (similar to current wide opcode).
They would have meaning only before integer arithmetic opcode like iadd, imul,
ladd etc. First bytecode would be overflow and would cause following instruction
to throw some kind of exception on overflow (probably subclass of
ArithmeticException). Second bytecode would be saturate and would cause
following computation to saturate to min or max value for given type on
overflow.
Implementation should be straighforward on most architectures. For processors
not implementing saturate, explicit branch with check for overflow could be
made. This won't be extremly fast, but anyway a lot faster and safer that any
manual handling that can be done with current bytecode.
Question how it could be expressed in java language is quite another thing.
This is not most important (as jvm is meant not only to run java). My proposal
would be something like synchronized block -
overflow {
x = y*z;
}
saturate {
gray = a+b+c;
}
All computation inside block would be modified by given mode. Some shortcut could be made for OverflowException -
overflow {
x = y*z;
} catch (OverflowException exc )
{
//handle exc
}
Both modifier could probably be also applied to casts - currently narrowing cast is just truncucating the bits, with overflow/sature modifiers it could change
meaning a bit.
Both modifiers should certainly affect i/l add/sub/mul. They could also be
implemented for shifts and casts (as mentioned above).
(Review ID: 125890)
======================================================================
###@###.### 10/22/04 20:38 GMT
Applicable to all jdks.
Currently jvm does not provide explicit way to handle overflow on integer
arithmetics. There is an easy way to detect this in most hardware, but
overflow flags are not exposed at bytecode layer. There are groups of
applications which need to either detect overflow (and react accordingly) or
perform saturated arithmetics (mostly graphics apps).
There are ways to work around that (see below at workaround section), but they
are both slow and sometimes tricky. With simple change to bytecode it could be
made more explicit.
I would propose to add two modifier bytecodes (similar to current wide opcode).
They would have meaning only before integer arithmetic opcode like iadd, imul,
ladd etc. First bytecode would be overflow and would cause following instruction
to throw some kind of exception on overflow (probably subclass of
ArithmeticException). Second bytecode would be saturate and would cause
following computation to saturate to min or max value for given type on
overflow.
Implementation should be straighforward on most architectures. For processors
not implementing saturate, explicit branch with check for overflow could be
made. This won't be extremly fast, but anyway a lot faster and safer that any
manual handling that can be done with current bytecode.
Question how it could be expressed in java language is quite another thing.
This is not most important (as jvm is meant not only to run java). My proposal
would be something like synchronized block -
overflow {
x = y*z;
}
saturate {
gray = a+b+c;
}
All computation inside block would be modified by given mode. Some shortcut could be made for OverflowException -
overflow {
x = y*z;
} catch (OverflowException exc )
{
//handle exc
}
Both modifier could probably be also applied to casts - currently narrowing cast is just truncucating the bits, with overflow/sature modifiers it could change
meaning a bit.
Both modifiers should certainly affect i/l add/sub/mul. They could also be
implemented for shifts and casts (as mentioned above).
(Review ID: 125890)
======================================================================
###@###.### 10/22/04 20:38 GMT
- relates to
-
JDK-8301226 Add clamp() methods to java.lang.Math and to StrictMath
- Resolved