Re: Null check elimination & other stuff
Miroslaw Dobrzanski-Neumann <[email protected]>
| Newsgroups | gmane.comp.gnu.dotgnu.developer |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]] > > Sent: Wednesday, 16 June 2004 08:18 > > To: [email protected] > > 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: [email protected] This message is utf-8 encoded