Undefined behaviour in hotspot

[Volker Simonis]

Hi Christian,

while I think that this change is good, it meanwhile turned out that
calling a method on a zero this pointer was not the real cause of the
problem (see the problem analysis in this thread and in
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013614.html).

Regards,
Volker


On Fri, Apr 25, 2014 at 4:10 AM, Christian Thalinger
<christian.thalinger at oracle.com> wrote:
>
> On Apr 24, 2014, at 10:33 AM, Christian Thalinger
> <christian.thalinger at oracle.com> wrote:
>
>
> On Apr 21, 2014, at 10:41 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
> Hi,
>
> I think the simplest and safest fix would be to make encoding() (and
> all the corresponding functions) static functions which take a
> Register as argument like:
>
> static int encoding(const RegisterImpl* r) { assert(is_valid(r),
> "invalid register"); return (intptr_t)r; }
>
> This wouldn't waste any more memory and it would be fully C++
> compliant at the price of a slightly more verbose usage:
>
> 2577    void Assembler::push(Register src) {
> 2578      int encode = prefix_and_encode(RegisterImpl::encoding(src));
> 2579
>
> And of course this would work with any compiler.
>
> What do you think?
>
>
> I’d rather make Register a real C++ class with an _encoding field.  There
> are not that many registers used or allocated that it would make a big
> difference in memory usage.
>
>
> I filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8041796
>
> and here is an initial cut of the changes:
>
> http://cr.openjdk.java.net/~twisti/8041796/webrev.00/
>
> Right now it’s x86 only and of course must be done for all the other
> architectures as well.  By inspecting some Clang generated code it seems the
> resulting code is the same in most (all?) cases.
>
>
>
> Regards,
> Volker
>
>
> On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid <omajid at redhat.com> wrote:
>
> * David Chase <david.r.chase at oracle.com> [2014-04-21 13:53]:
>
>
> On 2014-04-21, at 12:17 PM, Omair Majid <omajid at redhat.com> wrote:
>
> I can ping them, but honestly, I wouldn't be surprised at all if the
> only response I get is "no". I don't have any official communication
> channels with them, so my input is not any different from anyone else's.
>
> Can you elaborate on what flag/pragma you have in mind? Just something
> to play nice with NULL pointers?
>
>
> Not just null pointers.  Also optimizations that pretend that integer
> overflow
> doesn't happen (i.e., optimizations that change program behavior when it
> does) also need to be disabled.
>
>
> My knowledge of C/C++ is fairly limited, so please bear with me. There
> are a few relevant options already listed in 'man gcc':
>
> -Wstrict-overflow=n
>          This option is only active when -fstrict-overflow is active.
>          It warns about cases where the compiler optimizes based on
>          the assumption that signed overflow does not occur
>
> -fwrapv
>          This option instructs the compiler to assume that signed
>          arithmetic overflow of addition, subtraction and
>          multiplication wraps around using twos-complement
>          representation.
>
> Do you mean others?
>
> Thanks,
> Omair
>
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>
>