RE: Null check elimination & other stuff

> -----Original Message-----
> From: Miroslaw Dobrzanski-Neumann [mailto:[email protected]]
> Sent: Wednesday, 16 June 2004 18:39
> To: [email protected]
> Subject: Re: [DotGNU]Null check elimination & other stuff
> 
> On Wed, Jun 16, 2004 at 08:52:29AM +1200, Thong (Tum) Nguyen wrote:
> > That's what I started investigating.  Unfortunately, I don't have access
> to
> > an AIX box to verify that it actually works as intended (might have
> > permissions to read from 0x0 but not permissions to change its
> permissions).
> >
> > The bigger problem (or so I thought) was what would happen if the user
> > dereferenced a null reference to the last field of a sufficiently large
> > class.  It looks like CVM generates COP_CKNULL on fields where the
> offset >
> > 255 so it as long as the first page generates a SEGV (and page_size >
> 255),
> > it's perfectly safe.  This is probably something the JITCoder will have
> to
> > deal with if it hasn't already....
> 
> I picked 256 as a random value it has nothing to do with the one used by
> xlc.
> Usually the page size is much bigger than 256 Bytes. The common value is
> 4096
> or even 8192 so you can test against the whole page size
> twllti rX,4096
> which reads: generate a trap if (unsigned)rX < 4096

I was talking about CVM not xlc.  The field load/store opcodes use a byte to
specify the offset.  Any fields with larger offsets use wide memory
load/store opcodes which always do explicit null checks.  And yeah, page
sizes are much bigger than 256 which is why I said the null check
elimination code is safe for both linux & windows which are the only enabled
targets atm.

I'm not sure whether it's a good idea to generate a trap (at least by
default) on systems where *((void *)(0)) == 0.  Some native code (which
could be p/invoked) might rely on it.

Regards,

^Tum