public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Sturm <jsturm@one-point.com>
To: Andrew Haley <aph@cambridge.redhat.com>
Cc: Bryce McKinlay <bryce@waitaki.otago.ac.nz>,
	tromey@redhat.com, Dan Nicolaescu <dann@godzilla.ics.uci.edu>,
	java@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: java aliasing rules
Date: Thu, 04 Apr 2002 14:20:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.10.10204041559090.14734-100000@mars.deadcafe.org> (raw)
In-Reply-To: <15532.46863.497218.134876@cuddles.cambridge.redhat.com>

On Thu, 4 Apr 2002, Andrew Haley wrote:
>  > > Right, its not optimal scheduling, but there's no way to avoid that and 
>  > > still have the correct behaviour for NullPointers. And as you suggest, a 
>  > > modern processor may be speculativly executing the following loads, so 
>  > > it probibly doesn't matter too much.
> 
> If it doesn't annul such speculation on SEGV I don't think it's
> correct Java semantics.

I've been told that EV6 does, don't know about others.  (CPUs are complex
beasts nowadays, that's for sure.)

>  > It might be useful to turn this "correctness" off with a compiler option,
>  > as we do with -fno-bounds-check.  I habitually check for null in my code,
>  > and don't do anything useful with a NullPointerException besides aborting.
>  > I suspect that's true of a great deal of Java code.
> 
> I know what you mean, but turning this off is a pretty major departure
> from the Java language spec.

Perhaps.  There are days I wonder if Java is the language I need.  What
I'd really like is Java that easily binds to C++ code... um, never
mind ;)

Jeff

  reply	other threads:[~2002-04-04 21:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-27 11:43 Dan Nicolaescu
2002-03-27 13:53 ` Tom Tromey
2002-03-27 16:03   ` Dan Nicolaescu
2002-03-27 16:47     ` Tom Tromey
2002-03-27 20:00       ` Dan Nicolaescu
2002-03-27 15:54 ` Bryce McKinlay
2002-03-27 16:45   ` Tom Tromey
2002-03-28 22:02     ` Bryce McKinlay
2002-03-28 22:13       ` Richard Henderson
2002-03-28 22:15       ` Tom Tromey
2002-03-29 15:22         ` Bryce McKinlay
2002-03-29 16:26           ` Richard Henderson
2002-03-30  6:37           ` Jeff Sturm
2002-03-30 13:55             ` Richard Henderson
2002-03-30 15:04             ` Bryce McKinlay
2002-04-04 10:57               ` Jeff Sturm
2002-04-04 12:57                 ` Andrew Haley
2002-04-04 14:20                   ` Jeff Sturm [this message]
2002-04-04 17:04                 ` Bryce McKinlay
2002-04-04 20:39                   ` Jeff Sturm
2002-04-05  1:07                     ` Bryce McKinlay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.10.10204041559090.14734-100000@mars.deadcafe.org \
    --to=jsturm@one-point.com \
    --cc=aph@cambridge.redhat.com \
    --cc=bryce@waitaki.otago.ac.nz \
    --cc=dann@godzilla.ics.uci.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=java@gcc.gnu.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).