Paladin of the Pegasos
Posts: 1193 from 2003/2/24
From: Helsinki, Finland
This definitely affects
every webkit-based browser out there. Sure, on many platforms it only means that leaked memory will slowly pile up in swap (which doesn't really slow down system that much, as once there, it never needs to be accessed). Sure, it goes "via ram" (swapped out when some other program needs it), but that's about it.
Basically means that if you are low on memory + swap or do some REALLY heavy browsing, you have to restart browser once or twice a day.
This far, I intentionally left out one
very major hardware group: mobile phones & tablets. There, these memory issues are much worse, due to less ram & swap.
The point is,
if it was easy to fix, some of the "big players" (Apple, Google, KDE, Opera...) would have already done that. If they can't, what hope would a lone MorphOS coder have?
Of course Firefox engine is "at least as bad", and considering even Apple picked 3rd party solution, rather than creating an own closed one should prove how big task creating a proper web engine from scratch would be.
As for (not) checking memory allocations, why isn't it done then?
Simple answer: (on some platforms, namely those it was developed on), the only difference memory allocations would do is increase binary size (and memory requirements) slightly.
Consider following (slightly technical):
Quote:
// Assuming size is >0 and either there is or isn't enough memory available:
if((allocation=malloc(size)))
{
// MorphOS never ends up here, unless there was enough memory for allocation.
allocation[0]=value;
// On linux, if there was not enough memory available, kernel notices it during the previous call, and kills a seemingly random task (which might or might not be the one that caused running out of memory) to free memory.
// If allocation was successful, MorphOS always reaches this point without problems.
}
else
{
// Memory allocation failed.
// MorphOS ends up here, if there wasn't enough memory available.
// Linux practically never ends up here, especially on 64bit systems.
// Linux CAN end up here, if user tries to make an allocation, that exceeds the virtual memory the task has left. This has nothing to do with available memory, and is basically "how many different addresses can be represented by 32/64/whatever bits. On 32bits that's 4 gigabytes (- some used by kernel), on 64 bit... Well, each additional bit doubles the amount.
}
That assuming "default" linux settings. As you can see, the allocation check doesn't really make much difference there.
Fab:
Would it be possible to make download manager a somewhat separate program, that would crash independently from OWB? (Meaning, if I have to quit OWB, downloads would still keep running)
