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 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 funct
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 ma
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, 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
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 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
"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 calculate the generation of a particular
> 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 fu
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, the
> >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 calli
At 02:23 AM 5/20/2002 -0400, Mike Lambert wrote:
>GC-sensitive functions must remember to mark themselves as critical.
>This will be a source of bugs (whether that's a big enough of a
>complaint is up for debate. ;)
I'll think about debating it tomorrow. :)
>Most vtable methods, and/or people th
> 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
13 matches
Mail list logo
