i'm sure you could fathom the idea that some people care more about
streaming video on their browsers than address randomization, the same
way some people care more about speedier local lookups to a
stationary sync db than making sure a package has correct @want-lib
by trashing the ftp server on
On Sat, Jun 4, 2011 at 10:39 AM, Marc Espie es...@nerim.net wrote:
Well, the official fix for mono is in, from the mono team.
Guess what ? Mono uses MAP_32BIT if it's available.
From Linux's mmap manpage:
MAP_32BIT (since Linux 2.4.20, 2.6)
Put the mapping into the first 2
On Fri, Jun 3, 2011 at 6:26 PM, Marc Espie es...@nerim.net wrote:
On Fri, Jun 03, 2011 at 06:11:31PM -0400, Nico Kadel-Garcia wrote:
On Tue, May 31, 2011 at 6:51 AM, Marc Espie es...@nerim.net wrote:
How comes nobody in other OSes noticed ? Well, people probably did, and
tweaked their
On Sun, Jun 05, 2011 at 09:46:48AM -0400, Nico Kadel-Garcia wrote:
On Fri, Jun 3, 2011 at 6:26 PM, Marc Espie es...@nerim.net wrote:
On Fri, Jun 03, 2011 at 06:11:31PM -0400, Nico Kadel-Garcia wrote:
On Tue, May 31, 2011 at 6:51 AM, Marc Espie es...@nerim.net wrote:
How comes nobody in
On 4 June 2011 08:48, Amit Kulkarni amitk...@gmail.com wrote:
How comes nobody in other OSes noticed ? Well, people probably did, and
tweaked their allocators to work, by using preferably the low address
space,
and having addresses that increase slowly, so that a lot of pointers are
below
Well, the official fix for mono is in, from the mono team.
Guess what ? Mono uses MAP_32BIT if it's available.
From Linux's mmap manpage:
MAP_32BIT (since Linux 2.4.20, 2.6)
Put the mapping into the first 2 Gigabytes of the process
address space. This flag is
On Tue, May 31, 2011 at 6:51 AM, Marc Espie es...@nerim.net wrote:
How comes nobody in other OSes noticed ? Well, people probably did, and
tweaked their allocators to work, by using preferably the low address space,
and having addresses that increase slowly, so that a lot of pointers are below
On Fri, Jun 03, 2011 at 06:11:31PM -0400, Nico Kadel-Garcia wrote:
On Tue, May 31, 2011 at 6:51 AM, Marc Espie es...@nerim.net wrote:
How comes nobody in other OSes noticed ? Well, people probably did, and
tweaked their allocators to work, by using preferably the low address
space,
and
How comes nobody in other OSes noticed ? Well, people probably did, and
tweaked their allocators to work, by using preferably the low address
space,
and having addresses that increase slowly, so that a lot of pointers are
below
4GB, and a lot of pointer diffs are under 4GB.
Or you could
On 2011-06-01 04.58, Damien Miller wrote:
The recent trend of forking another process for a tab instead of a
monolithic single process for the whole browser is a way of extending
the time required to clean up this mess? Or there is no relation
between them?
I cannot look into the heads of the
@ Corey clinge...@gmail.com wrote (2011-06-01 04:39+0200):
I mean, come on -- storing data in unused bits in a pointer? Even
I know that's a bad idea.
But really, there are user-space memory pools which align on 8 or
16 byte boundaries, so here you have at least three perfectly fine
bits.
On Wed, Jun 01, 2011 at 01:48:03PM +0200, Steffen Daode Nurpmeso wrote:
@ Corey clinge...@gmail.com wrote (2011-06-01 04:39+0200):
I mean, come on -- storing data in unused bits in a pointer? Even
I know that's a bad idea.
But really, there are user-space memory pools which align on 8 or
On Tue, May 31, 2011 at 11:51 PM, bofh goodb...@gmail.com wrote:
This is interesting. I would really appreciate it very much if you don't
mind elaborating a bit more for a non-programmer? Thanks!
The general idea which I believe is used by JS engines is to notice
that javascript has two
On 1 June 2011 00:13, Theo de Raadt dera...@cvs.openbsd.org wrote:
On Tue, May 31, 2011 at 10:39 PM, Corey clinge...@gmail.com wrote:
data in unused bits in a pointer? Even I know that's a bad idea. Is
it
really that important to run your Javascript 2% faster?
The difference is quite a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 01 Jun 2011 04:42:02 + annathemerm...@hush.com wrote:
On 31 May 2011 19:51, Otto Moerbeek o...@drijf.net wrote:
On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber
wrote:
Marc Espie es...@nerim.net wrote:
Not surprisingly,
On Tue, May 31, 2011 at 12:51:27PM +0200, Marc Espie wrote:
People not following development too closely may not be aware of it,
but we've had a lot of fun with amd64 recently.
Specifically, Ariane committed a new vmmap implementation that tends to
actually use the 64 bits address space, in
On Wed, 1 Jun 2011 17:49:47 +0200
Peter J. Philipp wrote:
Not sure if it's OpenBSD's mission to include a browser but
Google and Apple seem to think bundling a browser with their OS's is a must,
even if they suck at it.
OSS - OpenBSD Secure Surfer or something - Would certainly make the
Ariane van der Steldt wrote:
On Tue, May 31, 2011 at 03:28:11PM -0500, Amit Kulkarni wrote:
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination
logic.
@ Otto Moerbeek o...@drijf.net wrote (2011-06-01 14:12+0200):
Storing tag bits in the lower bits of a pointer can be ok indeed if
you know things about alignment restrictions.
Of course it all stands and falls with the quality of the memory
allocator! If that sucks your canary's chirp beeps
@ Alexey Suslikov alexey.susli...@gmail.com wrote (2011-06-01 21:04+0200):
Why do they need such a trick instead of simply storing tags in a
associative array, where key is a pointer and value is a set of tags
(or any other arbitrary data)? Lookup against properly aligned array
is relatively
People not following development too closely may not be aware of it,
but we've had a lot of fun with amd64 recently.
Specifically, Ariane committed a new vmmap implementation that tends to
actually use the 64 bits address space, in userland. She even has some
more nasty diff that does its best
Marc Espie es...@nerim.net wrote:
Not surprisingly, a lot of software that claims to be 64 bits-ready isn't.
This touches all web navigators, most jit engines, and probably lots more
of software (our ports tree version of gnu-grep, for instance).
I don't think a lot suffers from it, but some
On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber wrote:
Marc Espie es...@nerim.net wrote:
Not surprisingly, a lot of software that claims to be 64 bits-ready isn't.
This touches all web navigators, most jit engines, and probably lots more
of software (our ports tree version
On Tue, 31 May 2011 21:51:40 +0200
Otto Moerbeek wrote:
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
On Tue, May 31, 2011 at 08:58:29PM +, Kevin Chadwick wrote:
On Tue, 31 May 2011 21:51:40 +0200
Otto Moerbeek wrote:
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
webkit tries to do this.
-Otto
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
Of course they do, otherwise they wouldn't run at all.
google for MAP_32BIT.
Once you've read enough to get sick to your stomach, please realize
that this is just the tip of the
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
Of course they do, otherwise they wouldn't run at all.
google for MAP_32BIT.
Once you've read enough to get sick to your stomach, please realize
that this is just the tip of
On Tue, May 31, 2011 at 03:28:11PM -0500, Amit Kulkarni wrote:
basically rewriting the memory
management part of the OS in your browser.
Do some browsers do this on OpenBSD?
Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination
logic. It even has its own code to map files
Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination
logic. It even has its own code to map files in. However, the managed to
avoid the common pitfall of requiring all platforms to have 4 kB pages:
they hardcoded to 8 kB instead.
And for those who don't know, OpenBSD has some
On 05/31/2011 06:26 PM, Theo de Raadt wrote:
Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination
logic. It even has its own code to map files in. However, the managed to
avoid the common pitfall of requiring all platforms to have 4 kB pages:
they hardcoded to 8 kB instead.
And
On Wed, 1 Jun 2011, Ariane van der Steldt wrote:
The recent trend of forking another process for a tab instead of a
monolithic single process for the whole browser is a way of extending
the time required to clean up this mess? Or there is no relation
between them?
I cannot look into
On Tue, May 31, 2011 at 10:39 PM, Corey clinge...@gmail.com wrote:
data in unused bits in a pointer? Even I know that's a bad idea. Is it
really that important to run your Javascript 2% faster?
The difference is quite a bit more than 2%. The technique is sound,
imo, but it seems the
On Tue, May 31, 2011 at 10:39 PM, Corey clinge...@gmail.com wrote:
data in unused bits in a pointer? Even I know that's a bad idea. Is it
really that important to run your Javascript 2% faster?
The difference is quite a bit more than 2%. The technique is sound,
imo, but it seems the
On Tue, May 31, 2011 at 11:03 PM, Ted Unangst ted.unan...@gmail.com wrote:
On Tue, May 31, 2011 at 10:39 PM, Corey clinge...@gmail.com wrote:
data in unused bits in a pointer? Even I know that's a bad idea. Is
it
really that important to run your Javascript 2% faster?
The difference is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31 May 2011 19:51, Otto Moerbeek o...@drijf.net wrote:
On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber
wrote:
Marc Espie es...@nerim.net wrote:
Not surprisingly, a lot of software that claims to be 64 bits-
ready isn't.
This
35 matches
Mail list logo
