lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Some questions about linux kernel.
Date
On Tue, 21 Mar 2000 17:59:28 -0600 (CST), you wrote:
>On Tue, 21 Mar 2000, James Sutherland wrote:
>
>> Certainly, changing malloc() so it, in Java parlance, "raises an
>> exception" (i.e. signals the process "something's gone pearshaped
>> here") would help.
>
>How? With overcommitting of memory, the only way to know if that memory
>you just allocated is to:
>1) Allocate the memory
>2) check to see if the return from malloc() is null and throw an exception
>if it is.
No - if you write to address 0, this will lead to a signal anyway. No
overhead here.
>3) Set the SIGSEGV signal handler to a special handler
Do this statically at init, once per process.
>4) memset the memory to 0, touching every single page
>5) If the memset segfaulted:
> 5a) long jump out of the signal handler
> 5b) reset the signal handler
> 5c) free the memory (we never really allocated it anyways)
> 5d) throw an exception
>6) reset the signal handler
>7) return the pointer to the allocated memory.

No; for the typical case, you just install a signal handler once, when
the app starts, then you can call malloc() and write to the resulting
address without any further checks at all.

If malloc() fails and you write to the (duff) "address" it returned,
you get signalled. If it succeeds, but you can't allocate the memory,
you get signalled. Then your signal handler just flushes all your
buffers and exits, or garbage collects and retries, or whatever.

MUCH simpler, IMHO.

>This is the problem with overcommitting memory: if you actually care
>enough to try and write a program to do something sane on OOM, your life
>has been made enormously more difficult.
>
>> The number of apps which call malloc(), get zero,
>> then try reading from or writing to their nice new buffer at address
>> 0...
>
>"Everyone else writes bad code- why should I write good code?"
>
>>
>> Handling one signal is a lot easier than checking every single return
>> value from every single call, which is what you would need to handle
>> OOM properly otherwise...
>
>There is a difference between _allowing_ bad programming techniques, and
>_requiring_ them. By overcommitting memory, you make checking the return
>value of malloc useless. If you don't check the return value, and you're
>out of memory, the behavior is the same either way- the program segfaults
>(either by attempting to access overcommitted memory, or by dereferencing
>a NULL pointer). If you do check those return values...
>
>And most large projects _do_ override malloc with something similiar to:
>
>void * xmalloc (size_t size) {
> void * retval = malloc(size);
> if (retval == NULL) longjmp(nomem_handler);
> return retval;
>}
>
>Actually, that's an iffy statement today, and the trend is definately
>towards better error handling. Consider all the code written in languages
>like Perl, Python, and Java.

Much better, IMO, to replace that whole mess with a nice "OOM signal".
No need to check return values, no need to compare things - MUCH less
overhead in the typical case (success).


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.144 / U:1.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site