Sean O'Rourke wrote:
How true. On Solaris, for example, mmap's are aligned on 64k boundaries,
which leads to horrible virtual address space consumption when you map
lots of small things. If we're mmap()ing things, we want to be sure
they're fairly large.
Is one PBC file a small thing? Or in
Dan Sugalski wrote in perl.perl6.internals :
In Perl terms, assume we have a method PRE that gets called before
any method in a class is called, and AUTOLOAD which is called if you
call a method on a class and that method doesn't exist. Does AUTOLOAD
have to get called to check for PRE if
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote:
The problem's actually _virtual_ memory use/fragmentation, not physical
memory or swap. Say you map in 10k small files -- that's 640M virtual
memory, just over a fourth of what's available. Now let's say you're also
using mmap()
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
Is one PBC file a small thing? Or in other words, should we have a low
limit where we start again to malloc and copy PBC files?
Configure option? Commandline switch?
Maybe a config option? The app I'm thinking of was pathological, in that
it mapped
On 01/25/2003 4:26 AM, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also some way of storing a cryptographic signature in the file, so
that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
The palladium parrot :)
Just because it's possible to use a
On 01/26/2003 2:18 PM, Sean O'Rourke wrote:
Maybe a config option? The app I'm thinking of was pathological, in that
it mapped in thousands of 20-byte files. Now that I think about it,
unless someone implements something very strangely (or has absolutely
enormous numbers of threads) this
