-
Bug
-
Resolution: Fixed
-
P3
-
1.0
-
1.1
-
sparc
-
solaris_2.4
-
Not verified
[Tim, 7/30/96:]
I no longer think that it is reasonable to expect that the monitor cache expansion
code should be able to survive malloc failures better than anything else in the
runtime, so that this is not actually a bug. The one exception is when expanding
the monitor cache hash table. If that fails the system should continue, using the
old one. Performance may degrade, but there's no reason to fail.
[Original report]
If we run out of memory when trying to allocate a monitor from the monitor
cache (i.e. we failed to get memory to expand the cache) we currently just croak
the interpreter by calling out_of_memory(). We should be throwing an
OutOfMemoryError instead, although when it comes down to it, it's not clear
that the user will be able to free up malloc space without using a monitor.
Note also that failing to expand the monitor cache hash table needs *NEVER* be
a fatal error. If malloc fails when trying to allocate the new hash table, we can
certainly go on using the old one. We should ensure that a subsequent monitor
allocation will try to expand the table again, and hope that space has freed
up by then.
I no longer think that it is reasonable to expect that the monitor cache expansion
code should be able to survive malloc failures better than anything else in the
runtime, so that this is not actually a bug. The one exception is when expanding
the monitor cache hash table. If that fails the system should continue, using the
old one. Performance may degrade, but there's no reason to fail.
[Original report]
If we run out of memory when trying to allocate a monitor from the monitor
cache (i.e. we failed to get memory to expand the cache) we currently just croak
the interpreter by calling out_of_memory(). We should be throwing an
OutOfMemoryError instead, although when it comes down to it, it's not clear
that the user will be able to free up malloc space without using a monitor.
Note also that failing to expand the monitor cache hash table needs *NEVER* be
a fatal error. If malloc fails when trying to allocate the new hash table, we can
certainly go on using the old one. We should ensure that a subsequent monitor
allocation will try to expand the table again, and hope that space has freed
up by then.