Re: [DotGNU]Null check elimination & other stuff

[Miroslaw Dobrzanski-Neumann]

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

if there were a structure larger than page size the engine (cvm/libjit) could
generate another check for it.

> 
> Regards,
> 
> ^Tum
> 
> > -----Original Message-----
> > From: Rhys Weatherley [mailto:address@hidden
> > Sent: Wednesday, 16 June 2004 08:18
> > To: address@hidden
> > Subject: Re: [DotGNU]Null check elimination & other stuff
> > 
> > On Wednesday 16 June 2004 02:30 am, Thong (Tum) Nguyen wrote:
> > 
> > > Weird.  Is it possible to simply mark the first page as not readable?
If IBM doesn't do it there must be a good (maybe internal) reason for (not) 
doing
that.

> > 
> > You can probably use mprotect to change the permissions on the zero page.
> > Have a look at Kaffe.  I seem to recall that it does this on some
> > platforms.

you can't use mprotect() on memory not allocated with mmap()!

> > 
> > Anyway, it is OK to do manual null checks on platforms where it is too
> > hard to
> > do the tricky null checks.

trap and SIGTRAP handler may produce a faster code under the assumption the
trap will never be generated.

Regards
        Mirosław
-- 
Mirosław Dobrzański-Neumann

MOSAIC SOFTWARE AG
E-mail: address@hidden

This message is utf-8 encoded