On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
But there are two kinds of available here: available without asking the
operating system for more; and available period. If we're in the first
situation, it seems reasonable to just ask the OS for a new block and keep
going,
On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
Since our memory-allocating routines return NULL quite a ways back up the
call chain (all the way through e.g. string_grow()), here's another way to
do this -- if allocation returns NULL all the way to an op function, it
can make
On Tue, 28 May 2002, Jerome Vouillon wrote:
That's an interesting point, actually. What is the right thing to do
when we run out of memory?
- Abort immediately.
This is not very user-friendly.
- Return a special value.
But then we need to check the return value of almost all functions
Sean O'Rourke:
# On Tue, 28 May 2002, Jerome Vouillon wrote:
# That's an interesting point, actually. What is the right
# thing to do
# when we run out of memory?
# - Abort immediately.
#This is not very user-friendly.
# - Return a special value.
#But then we need to check the
On Sun, May 26, 2002 at 08:20:23AM -0700, Sean O'Rourke wrote:
I'm sure it's been discussed before somewhere, but why can't we guarantee
that we only do GC runs between ops? Each op would just have to guarantee
that all of its persistent data is reachable before it returns. It seems
like
On Mon, 27 May 2002, Jerome Vouillon wrote:
On Sun, May 26, 2002 at 08:20:23AM -0700, Sean O'Rourke wrote:
I'm sure it's been discussed before somewhere, but why can't we guarantee
that we only do GC runs between ops? Each op would just have to guarantee
that all of its persistent data
Add a counter to the interpreter structure, which is incremented every
opcode (field size would not be particularly important)
Store this counter value in every new object created, and set the 'new
object' flag (by doing this on every object, we remove the requirement for
the creating
On Sun, 26 May 2002, Peter Gibbs wrote:
Mike Lambert wrote:
I know Dan's proposed solution has already been committed, but I'd
like to add my support for this. In addition to providing a counter per
opcode to ensure that we don't prematurely GC data, this field could also
be reused to
I would like an elegant, easy to use solution for making the GC
play nicely.
So would we all. :)
This creates a sliding scope window that GC must not peep through,
and provides a clean interface for internals writers.
I think you've explained this idea before, but I complained about it
Most vtable methods, and/or people that call vtable methods, will end up
making themselves critical. This overhead will be imposed on most function
calls, etc. Lots of the string api will require the users to mark
themselves as critical.
I don't think this is accurate. People calling vtable
I submitted a patch to implement the initial parts of Dan's method some time
ago, which has never been applied. (Although Dan recently agreed that it
needed to be done, and I will be updating it shortly in line with changes to
the memory management system) However, thinking about it some more,
I'm remailing this idea since we haven't discussed it in a while.
I would like an elegant, easy to use solution for making the GC
play nicely.
I propose a solution that allows us to draw a electric fence around
the current scope by using some call as follows:
gc_crit();
12 matches
Mail list logo
