Arithmetic overflow checking

Discussion in 'Java' started by rop rop, Jul 6, 2011.

  1. rop rop

    rop rop Guest

    Hi,

    If I want to have arithmetic-overflow checking in all parts of an
    application,
    what is the most practical, simple, efficient way to achieve this?
    Id like to clutter the code as little a possible...
    Is there any way to instruct the JVM to include it?
     
    rop rop, Jul 6, 2011
    #1
    1. Advertising

  2. rop rop

    Stefan Ram Guest

    rop rop <> writes:
    >If I want to have arithmetic-overflow checking in all parts of an
    >application,
    >what is the most practical, simple, efficient way to achieve this?
    >Id like to clutter the code as little a possible...


    One could use a JVM-based language with operator overloading.

    >Is there any way to instruct the JVM to include it?


    One also could write a bytecode-to-bytecode transformer
    that modifies arithmetic operations accordingly.
     
    Stefan Ram, Jul 6, 2011
    #2
    1. Advertising

  3. rop rop

    markspace Guest

    On 7/6/2011 8:35 AM, rop rop wrote:
    > Hi,
    >
    > If I want to have arithmetic-overflow checking in all parts of an
    > application,
    > what is the most practical, simple, efficient way to achieve this?
    > Id like to clutter the code as little a possible...
    > Is there any way to instruct the JVM to include it?



    Nope, can't be done. And yes I've griped about this myself, so you're
    in good (well, average at least) company.
     
    markspace, Jul 6, 2011
    #3
  4. rop rop

    Guest

    On Jul 6, 6:42 pm, markspace <-@.> wrote:
    > On 7/6/2011 8:35 AM, rop rop wrote:
    >
    > > Hi,

    >
    > > If I want to have arithmetic-overflow checking in all parts of an
    > > application,
    > > what is the most practical, simple, efficient way to achieve this?
    > > Id like to clutter the code as little a possible...
    > > Is there any way to instruct the JVM to include it?

    >
    > Nope, can't be done.  And yes I've griped about this myself, so you're
    > in good (well, average at least) company.


    OK...
    What about patching the JVM to add this (sadly missing) "feature"?
    It is open-source, isnt it?

    Nobody has done this already?
    Doesnt seems like a terribly big project, once I can locate the right
    place to do it...

    Any license aspects to consider, if I do it myself?
     
    , Jul 6, 2011
    #4
  5. rop rop

    markspace Guest

    On 7/6/2011 11:30 AM, wrote:

    > Doesnt seems like a terribly big project, once I can locate the right
    > place to do it...



    lol. Yeah right.

    http://openjdk.java.net/

    Good luck kid.
     
    markspace, Jul 6, 2011
    #5
  6. rop rop

    Tom Anderson Guest

    On Wed, 6 Jul 2011, Wanja Gayk wrote:

    > In article <015aeb15-57db-48ab-9cd4-
    > >, says...
    >
    >> If I want to have arithmetic-overflow checking in all parts of an
    >> application, what is the most practical, simple, efficient way to
    >> achieve this? Id like to clutter the code as little a possible... Is
    >> there any way to instruct the JVM to include it?

    >
    > Not automagically, at least if you want to avoid building a sourcecode-
    > preprocessor or tool that instruments your bytecode at class loading
    > time.


    Actually, a load-time bytecode manipulator might be the most practical way
    to do this. Modding the JVM is a non-starter for a few reasons, using an
    alternative language is not even a solution, using a library or a set of
    functions by convention is error-prone, but a bytecode weaver (using the
    java.lang.instrument API, to be clear) could do the job, and would be a
    fairly focused way of doing it - after the fairly small amount of
    boilerplate, it would just be a matter of decoding all targeted bytecode
    and rewriting it to check for overflow.

    I didn't say it would be easy, just focused.

    tom

    --
    History, I believe, furnishes no example of a priest-ridden people
    maintaining a free civil government. -- Thomas Jefferson
     
    Tom Anderson, Jul 6, 2011
    #6
  7. rop rop

    Roedy Green Guest

    On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <>
    wrote, quoted or indirectly quoted someone who said :

    >If I want to have arithmetic-overflow checking in all parts of an
    >application,
    >what is the most practical, simple, efficient way to achieve this?
    >Id like to clutter the code as little a possible...
    >Is there any way to instruct the JVM to include it?


    the JVM does not detect it because most hardware does not. You pretty
    well have to use long instead of int and mask off and check overflow.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    One thing I love about having a website, is that when I complain about
    something, I only have to do it once. It saves me endless hours of grumbling.
     
    Roedy Green, Jul 7, 2011
    #7
  8. rop rop

    Roedy Green Guest

    On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <>
    wrote, quoted or indirectly quoted someone who said :

    >If I want to have arithmetic-overflow checking in all parts of an
    >application,
    >what is the most practical, simple, efficient way to achieve this?
    >Id like to clutter the code as little a possible...


    If your hardware detects it, you could use some JNI and test the
    status codes and return a object containing the result and overflow
    info. Slow though.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    One thing I love about having a website, is that when I complain about
    something, I only have to do it once. It saves me endless hours of grumbling.
     
    Roedy Green, Jul 7, 2011
    #8
  9. In article <>,
    Patricia Shanahan <> wrote:

    > On 7/6/2011 8:35 AM, rop rop wrote:
    > >
    > > If I want to have arithmetic-overflow checking in all parts of an
    > > application, what is the most practical, simple, efficient way to
    > > achieve this?

    >
    > Write the application in Ada.


    In one popular implementation, the -gnato compiler option enables
    numeric overflow checking:

    <http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gnat_ugn_unw/Switches-for-gcc.html#Switches-for-gcc>

    The language defined attribute 'Machine_Overflows will indicate if
    checking is available for fixed or floating point types:

    <http://www.adaic.org/resources/add_content/standards/05rm/html/RM-K.html>

    JGNAT targets the JVM, but I haven't used it.

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, Jul 7, 2011
    #9
  10. rop rop

    rop rop Guest

    On Jul 6, 11:32 pm, Tom Anderson <> wrote:
    > Modding the JVM is a non-starter for a few reasons...


    Hi Tom,
    Thanks for input.
    Could you just elaborate on this, please... what is the main-problem
    with actually patching the JVM?
    Why is it so hard?
    Without having looked into the source-code, this seems like the most
    straight-forward and robust way to do it...
    Is the code so hard to penetrate or what?
     
    rop rop, Jul 7, 2011
    #10
  11. rop rop

    Stefan Ram Guest

    rop rop <> writes:
    >If I want to have arithmetic-overflow checking in all parts of an
    >application,
    >what is the most practical, simple, efficient way to achieve this?
    >Id like to clutter the code as little a possible...


    Even if you would be willing to use method calls in your
    source code, arithmetic overflow still could happen in
    library methods called by you. So it would not be sufficient
    to adjust only the source code written by you.

    Otherwise, if for some reason this should be sufficient,
    there is a Java 1.6 grammar for AntLR:

    http://www.antlr.org/grammar/list

    , so you could parse your source code with AntLR and this
    grammar, then transform all the operators to method calls
    (the precedence should already have been taken care of by
    the parser) and write out the result as source code again.
     
    Stefan Ram, Jul 7, 2011
    #11
  12. rop rop

    Eric Sosman Guest

    On 7/7/2011 3:30 AM, rop rop wrote:
    > On Jul 6, 11:32 pm, Tom Anderson<> wrote:
    >> Modding the JVM is a non-starter for a few reasons...

    >
    > Hi Tom,
    > Thanks for input.
    > Could you just elaborate on this, please... what is the main-problem
    > with actually patching the JVM?
    > Why is it so hard?
    > Without having looked into the source-code, this seems like the most
    > straight-forward and robust way to do it...
    > Is the code so hard to penetrate or what?


    The first thing that comes to mind is altering a JVM so it does
    not behave as described in the Java Virtual Machine Specification
    means you no longer have a JVM. Specifically, from section 2.4.2:
    "The built-in integer operators do not indicate (positive or negative)
    overflow in any way; they wrap around on overflow." For good or for
    ill, that's a requirement all JVM implementations must satisfy.

    But, okay, you start with a JVM and alter it to produce a "KWN"
    that behaves just like a JVM except in this one regard. Now a second
    difficulty arises: You start running Java on the KWN, and almost at
    once you get an arithmetic overflow exception. Investigating, you
    find that it occurred in a hashCode() method that's computing the
    time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
    a prime p. The overflow is entirely benign, yet "Hello".hashCode()
    stops your program in its tracks. So now you need a way to distinguish
    expected (benign) overflow from unanticipated (injurious) overflow --
    which means you need to alter not only the JVM but also Java. (Or maybe
    you could do something with annotations; I'm not sure.) But the main
    point is that all existing Java code expects overflow to wrap around,
    and lots of that code actually relies on wraparound.

    Finally, you've got definitional problems to sort out. For
    example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
    You need to put on your Language Legislator hat and think about it
    before you can decide how your KWN should behave.

    Personally, I wish integer over- and under-flow would in fact
    throw exceptions, and that the language had something like `unsigned'
    to allow the programmer to suppress the exceptions when appropriate.
    But that's a wish I don't expect to see fulfilled.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jul 7, 2011
    #12
  13. rop rop <> writes:

    > If I want to have arithmetic-overflow checking in all parts of an
    > application,
    > what is the most practical, simple, efficient way to achieve this?
    > Id like to clutter the code as little a possible...


    Without knowing anything about your application, I wonder if doing all
    the arithmetics with the BigInteger class instead of the int or long
    primitives would help. It shouldn't ever overflow according to the
    javadocs.
    Of course you may consider it not being practical and simple, and
    at least changing all the primitive numbers would mean changes to the
    code, but I haven't noticed any better suggestion so far.

    --
    Jukka Lahtinen
     
    Jukka Lahtinen, Jul 7, 2011
    #13
  14. rop rop

    rop rop Guest

    On Jul 7, 1:54 pm, Eric Sosman <> wrote:
    > On 7/7/2011 3:30 AM, rop rop wrote:
    >
    > > On Jul 6, 11:32 pm, Tom Anderson<>  wrote:
    > >> Modding the JVM is a non-starter for a few reasons...

    >
    > > Hi Tom,
    > > Thanks for input.
    > > Could you just elaborate on this, please... what is the main-problem
    > > with actually patching the JVM?
    > > Why is it so hard?
    > > Without having looked into the source-code, this seems like the most
    > > straight-forward and robust way to do it...
    > > Is the code so hard to penetrate or what?

    >
    >      The first thing that comes to mind is altering a JVM so it does
    > not behave as described in the Java Virtual Machine Specification
    > means you no longer have a JVM.  Specifically, from section 2.4.2:
    > "The built-in integer operators do not indicate (positive or negative)
    > overflow in any way; they wrap around on overflow."  For good or for
    > ill, that's a requirement all JVM implementations must satisfy.
    >
    >      But, okay, you start with a JVM and alter it to produce a "KWN"
    > that behaves just like a JVM except in this one regard.  Now a second
    > difficulty arises: You start running Java on the KWN, and almost at
    > once you get an arithmetic overflow exception.  Investigating, you
    > find that it occurred in a hashCode() method that's computing the
    > time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
    > a prime p.  The overflow is entirely benign, yet "Hello".hashCode()
    > stops your program in its tracks.  So now you need a way to distinguish
    > expected (benign) overflow from unanticipated (injurious) overflow --
    > which means you need to alter not only the JVM but also Java.  (Or maybe
    > you could do something with annotations; I'm not sure.)  But the main
    > point is that all existing Java code expects overflow to wrap around,
    > and lots of that code actually relies on wraparound.
    >
    >      Finally, you've got definitional problems to sort out.  For
    > example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
    > You need to put on your Language Legislator hat and think about it
    > before you can decide how your KWN should behave.
    >
    >      Personally, I wish integer over- and under-flow would in fact
    > throw exceptions, and that the language had something like `unsigned'
    > to allow the programmer to suppress the exceptions when appropriate.
    > But that's a wish I don't expect to see fulfilled.
    >
    > --
    > Eric Sosman
    >


    Thanks for clarification Eric -- besides no longer being a
    "JVM" (which I am aware of and dont care abt here),
    I now start to see the technical problems :)

    So one would also need a way to specify what classes overflow-checking
    should apply to,
    either a class-annotation,
    or perhaps a runtime-flag
    -Xcheckforoverflow.classes=my.firstpkg.*;my.secondpkg.*
    or similar would be practical.
     
    rop rop, Jul 7, 2011
    #14
  15. rop rop

    Tom Anderson Guest

    On Thu, 7 Jul 2011, rop rop wrote:

    > On Jul 6, 11:32 pm, Tom Anderson <> wrote:
    >> Modding the JVM is a non-starter for a few reasons...

    >
    > Could you just elaborate on this, please... what is the main-problem
    > with actually patching the JVM? Why is it so hard?


    It would involve modifying a bytecode interpreter and two just-in-time
    compilers, all three highly developed instances of their species, and all
    written in C++. How much do you know about interpreters and compilers, and
    how is your C++? I am a good Java programmer, but that task would be way
    beyond me.

    > Without having looked into the source-code, this seems like the most
    > straight-forward and robust way to do it...


    Prefixing a statement about some source code with 'without having looked
    at the source-code' pretty much disqualifies it completely.

    Tell you what: the source code to the x86 version of HotSpot is here:

    http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/

    In particular, here's the table of assembly instructions used for each
    bytecode in the interpreter:

    http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/templateTable_x86_32.cpp

    Have a look at that, and let me know how hard you think it would be to
    modify that to do overflow checking (and remember that you can't do it
    everywhere, because existing code is written to use overflow - you have to
    have some way of only doing it in specified bits of code).

    tom

    --
    Links are content.
     
    Tom Anderson, Jul 7, 2011
    #15
  16. On 07/07/2011 13:54, Eric Sosman allegedly wrote:
    > On 7/7/2011 3:30 AM, rop rop wrote:
    >> On Jul 6, 11:32 pm, Tom Anderson<> wrote:
    >>> Modding the JVM is a non-starter for a few reasons...

    >>
    >> Hi Tom,
    >> Thanks for input.
    >> Could you just elaborate on this, please... what is the main-problem
    >> with actually patching the JVM?
    >> Why is it so hard?
    >> Without having looked into the source-code, this seems like the most
    >> straight-forward and robust way to do it...
    >> Is the code so hard to penetrate or what?

    >
    > The first thing that comes to mind is altering a JVM so it does
    > not behave as described in the Java Virtual Machine Specification
    > means you no longer have a JVM. Specifically, from section 2.4.2:
    > "The built-in integer operators do not indicate (positive or negative)
    > overflow in any way; they wrap around on overflow." For good or for
    > ill, that's a requirement all JVM implementations must satisfy.
    >
    > But, okay, you start with a JVM and alter it to produce a "KWN"
    > that behaves just like a JVM except in this one regard. Now a second
    > difficulty arises: You start running Java on the KWN, and almost at
    > once you get an arithmetic overflow exception. Investigating, you
    > find that it occurred in a hashCode() method that's computing the
    > time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
    > a prime p. The overflow is entirely benign, yet "Hello".hashCode()
    > stops your program in its tracks. So now you need a way to distinguish
    > expected (benign) overflow from unanticipated (injurious) overflow --
    > which means you need to alter not only the JVM but also Java. (Or maybe
    > you could do something with annotations; I'm not sure.) But the main
    > point is that all existing Java code expects overflow to wrap around,
    > and lots of that code actually relies on wraparound.
    >
    > Finally, you've got definitional problems to sort out. For
    > example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
    > You need to put on your Language Legislator hat and think about it
    > before you can decide how your KWN should behave.
    >
    > Personally, I wish integer over- and under-flow would in fact
    > throw exceptions, and that the language had something like `unsigned'
    > to allow the programmer to suppress the exceptions when appropriate.
    > But that's a wish I don't expect to see fulfilled.
    >


    Not to mention the mess if it's an app you plan to distribute.

    --
    DF.
    Determinism trumps correctness.
     
    Daniele Futtorovic, Jul 7, 2011
    #16
  17. On Wed, 06 Jul 2011 22:41:54 -0700, Roedy Green
    <> wrote:

    >On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <>
    >wrote, quoted or indirectly quoted someone who said :
    >
    >>If I want to have arithmetic-overflow checking in all parts of an
    >>application,
    >>what is the most practical, simple, efficient way to achieve this?
    >>Id like to clutter the code as little a possible...
    >>Is there any way to instruct the JVM to include it?

    >
    >the JVM does not detect it because most hardware does not. You pretty
    >well have to use long instead of int and mask off and check overflow.


    Which hardware does not have overflow detection?

    x86 does have an overflow flag.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jul 7, 2011
    #17
  18. On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <>
    wrote:

    [snip]

    >I think the problem is more a matter of software knowing when overflow
    >should and should not be treated as an error.


    Exactly. C does not do that sort of checking, and the meme has
    spread widely. I would much prefer to have things blow up when wrong
    than not blow up. It makes for smaller messes.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jul 8, 2011
    #18
  19. rop rop

    lewbloch Guest

    On Jul 7, 5:12 pm, Gene Wirchenko <> wrote:
    > On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <>
    > wrote:
    >
    > [snip]
    >
    > >I think the problem is more a matter of software knowing when overflow
    > >should and should not be treated as an error.

    >
    >      Exactly.  C does not do that sort of checking, and the meme has
    > spread widely.  I would much prefer to have things blow up when wrong
    > than not blow up.  It makes for smaller messes.
    >


    the problem with that statement is that it's not wrong for Java
    primitive integer types to wrap around.

    It is, in fact, wrong for them to throw an overflow exception, as many
    have pointed out in this thread.

    --
    Lew
     
    lewbloch, Jul 8, 2011
    #19
  20. rop rop

    Eric Sosman Guest

    On 7/7/2011 8:51 PM, Peter Duniho wrote:
    > [...]
    > I would not worry about the "simple" or "efficient" criteria. IMHO, if
    > one is deciding to apply overflow checking to every computation, one has
    > already abandoned the hope of efficiency.


    I've used machines that raised overflow traps "for free," in
    the sense that it was done by the hardware/firmware/microcode, just
    like setting condition flags.

    Flipping the mode bit that enabled or disabled traps for integer
    arithmetic was relatively expensive, so programs tended to set it
    one way or the other during initialization and then just leave it
    alone. But it's not necessary to use a global bit to get this kind
    of behavior: an instruction set might feature both an AddAndWrap and
    an AddAndTrap instruction. True, that's not entirely free -- you
    pay for extra decoding logic in the instruction pipeline, for example.
    But the inefficiencies don't rise to the "abandon hope" level, IMHO.

    Besides: What are the relative efficiencies of an error caught
    and announced versus a wrong answer computed at great speed without
    any indication that it's wrong?

    (The machines I speak of were from forty-odd years ago and might
    be dismissed as ancientry, but their lineal descendants are still
    being made and sold. I don't know how today's editions deal with
    overflow, but if you're curious you can write to the vendor. Their
    headquarters are in Armonk, NY.)

    --
    Eric Sosman
    d
     
    Eric Sosman, Jul 8, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dlamoris
    Replies:
    0
    Views:
    896
    dlamoris
    Oct 26, 2006
  2. joshc
    Replies:
    5
    Views:
    576
    Keith Thompson
    Mar 31, 2005
  3. Fraser Ross

    arithmetic overflow with enum

    Fraser Ross, Oct 9, 2005, in forum: C++
    Replies:
    5
    Views:
    528
    Fraser Ross
    Oct 10, 2005
  4. darrel
    Replies:
    4
    Views:
    841
    darrel
    Jul 19, 2007
  5. tm

    Re: Arithmetic overflow checking

    tm, Jul 10, 2011, in forum: C Programming
    Replies:
    88
    Views:
    1,963
    Wolfgang Draxinger
    Sep 8, 2011
Loading...

Share This Page