Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #14234

Re: malloc

From glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups comp.lang.c, comp.lang.c++
Subject Re: malloc
Date 2012-02-18 15:30 +0000
Organization Aioe.org NNTP Server
Message-ID <jhog6s$331$1@speranza.aioe.org> (permalink)
References (2 earlier) <jhk2rh$19o$1@news.albasani.net> <Xns9FFCE79A6CA00myfirstnameosapriee@216.196.109.131> <01725059-5441-4441-804e-a201c15eeea1@m3g2000pbi.googlegroups.com> <jhn46t$dlp$1@news.albasani.net> <Xns9FFD68EF620ADmyfirstnameosapriee@216.196.109.131>

Cross-posted to 2 groups.

Show all headers | View raw


In comp.lang.c++ Paavo Helde <myfirstname@osa.pri.ee> wrote:
(snip)

>> the CPU to really make something like this all that workable, even
>> then it would still likely be page-fault driven slowness).

> This has been done in hardware as well. 
> http://en.wikipedia.org/wiki/Bounds_checking mentions VAX, B6500 and 
> Burroughs. By some reason this approach has not really catched on.

As I remember VAX allows pages to be marked read-only.
I remember Fortran compilers that would put constants in
read-only pages, such that they couldn't accidentally be 
modified. With call-by-reference, modification of constants
has a long history in Fortran.

>> one option that could sort of work for larger arrays would be 
>> to put unused pages between memory objects, such that going 
>> out of bounds is more likely to trigger a page fault.

> This is exactly what Electric Fence does. It is also slow as hell, 
> I guess the most slowdown comes from where the array ends in 
> a middle of a virtual memory page and efence 
(snip)

In the 16 bit OS/2 days, when most people were still using 16-bit
DOS, I would allocate arrays by directly calling the OS/2
segment allocation routine, for a segment exactly the size
required. That length then goes into the hardware segment
descriptor register, such that hardware tests the bounds,
even on fetch. That was before paging, though.
(Eventually you run into the 8K segment descriptor per
process limit, but usually it works pretty well.)

If Intel had added a segment descriptor cache to any of
the processors, it would have greatly speeded up some of the
things that were done in the 16 bit, and early 32 bit, OS/2 days.

If done right, it would have delayed the need for 64 bit
processors by some years.

-- glen

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

malloc jgk@panix.com (Joe keane) - 2012-02-16 21:04 +0000
  Re: malloc Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-16 13:21 -0800
    Re: malloc BGB <cr88192@hotmail.com> - 2012-02-16 16:16 -0700
      Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-17 14:46 -0600
        Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:51 -0800
          Re: malloc BGB <cr88192@hotmail.com> - 2012-02-17 19:58 -0700
            Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-18 02:18 -0600
              Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 01:58 -0700
              Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 15:30 +0000
            Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 10:36 +0000
            Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 16:43 -0800
              Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 20:03 -0700
                Re: malloc Miles Bader <miles@gnu.org> - 2012-02-19 12:49 +0900
                Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:08 -0800
                Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 18:23 +0100
                Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:06 -0800
                Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 23:06 -0700
      Re: malloc "Asger Joergensen" <Junk@Asger-P.dk> - 2012-02-19 15:54 +0000
        Re: malloc BGB <cr88192@hotmail.com> - 2012-02-19 09:37 -0700
    Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-16 20:27 -0500
      Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:40 -0800
        Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 02:26 -0800
          Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-17 04:01 -0800
            Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 09:25 -0800
              Re: malloc 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-17 09:37 -0800
              Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:49 -0800
                Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 01:43 +0000
                Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 02:04 +0000
                Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 03:04 +0000
                Re: malloc Robert Wessel <robertwessel2@yahoo.com> - 2012-02-17 22:15 -0600
                Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 23:48 -0800
              Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-17 23:29 +0000
        Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-17 08:06 -0500
          Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-18 07:57 -0800
            Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-18 10:57 -0800
            Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-19 08:51 -0500
      Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-17 20:31 +0000
        Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 00:01 -0800
          Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 17:07 +0000
            Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 18:14 -0800
              Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-19 17:14 +0000
  Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:43 -0800
  Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 16:44 +0100

csiph-web