On Mon, Apr 13, 2015 at 12:25:25AM -0400, Mark Montague wrote:
: Sorry for the noise.
No need to apologize--I thought it was interesting.
Larry
On 2015-04-12 11:22, Mark Montague wrote:
It is possible to build and run MoarVM on systems that prohibit
executable stacks? [...] Here's what happens when I try to build
Rakudo Star:
$ perl Configure.pl --backend=moar --gen-moar
[... lots of output ...]
Building NQP ...
/usr/bin
rakudo-star-2015.03, Fedora 21 x86_64
It is possible to build and run MoarVM on systems that prohibit
executable stacks? I have executable stacks and executable heaps turned
off for security reasons on my web servers. Here's what happens when I
try to build Rakudo Star:
$
On Monday 21 April 2008 19:17:34 Bob Rogers wrote:
> The hack is attached; it isn't headerized, has some coding standards
> failures, and leaks memory, so it's incomplete. Disappointingly, it
> produces an overall speedup of less than 4% in building gen_actions.pir
> in r27087 (which has chromati
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
;m now working on a simple hack that should show
how much speedup we can expect.
But the first step is eliminating the user stack, and I've
started on that now in the 'stacks' branch of the svn repo.
Pm
Excellent; thanks.
-- Bob
Am Montag, 21. April 2008 22:49 schrieb chromatic:
> On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> >
> > Thanks again. I was misreading from comments in stack_push, which
> > say that it pushes things onto the "generic
On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> Thanks again. I was misreading from comments in stack_push, which
> say that it pushes things onto the "generic stack" when in reality
> it seems to use whatever stack is pa
On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:25:53 -0500
>
>. . . this seems to be the case for everything using the
>"generic stack", which AFAICT is the &interp->dynamic_env structure.
>
>
lution that ought to speed up "bsr" dramatically:
> Give the "bsr" return addresses their own stack.
I thought of this also, but given that they share a stack currently
I figured the smaller delta would be to keep it that way. If it
looks like having a separate stack for bs
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:25:53 -0500
. . . this seems to be the case for everything using the
"generic stack", which AFAICT is the &interp->dynamic_env structure.
Your point is correct, except that you are talking about the "dynamic
envi
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:55:21 -0500
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableInt
On Mon, Apr 21, 2008 at 02:25:53PM -0500, Patrick R. Michaud wrote:
>
> The parts of the stack code we've discussed eliminating is actually
> the user_stack, used for push/pop/saveall/restoreall opcodes.
I inadvertently wrote push/pop here where I really meant save/restore.
The push/pop opcode
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote:
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableIntegerArray, where we allocate
> > arra
On Monday 21 April 2008 12:25:53 Patrick R. Michaud wrote:
> To me, the scary part of src/stacks.c is at the beginning:
>
> The stack is stored as a linked list of chunks (C),
> where each chunk has room for one entry.
>
> Eek! For something like bsr_ic, which is really just pushing a
> r
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> > I'm still exploring the Rakudo build progress as a profiling target for
> likely
> > optimizations. After this weekend's work, I have src/gen_actions.p
On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> I'm still exploring the Rakudo build progress as a profiling target for
> likely
> optimizations. After this weekend's work, I have src/gen_actions.pir
> generation down to 27,788,055,796 instructions (with an optimized Parrot). A
>
I'm still exploring the Rakudo build progress as a profiling target for likely
optimizations. After this weekend's work, I have src/gen_actions.pir
generation down to 27,788,055,796 instructions (with an optimized Parrot). A
big chunk of that time goes to support bsr_ic:
7,784,136,854 core.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46183]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46183 >
In src/gc/register.c:init_context() there is the todo item:
ctx->reg_stack = old->reg_
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... It *could* spill the used registers, or it could
> just push the whole set onto the register stack and start fresh,
> popping off the old set when the code's done.
Or probably much simpler: given a fairly big linear register frame, just
advance the ba
. I'm not inclined, yet, to drop
the register stacks and the push/pop ops as there are certainly
times when it's useful, being a quick way to spill and unspill a
set of registers for a basic block.
Not really IMHO. It doesn't get you more addressable registers, i.e.
you can always
Jeff Clites wrote:
Are we still planning to move the current return continuation and
current sub, out of the registers and into their own spots in the
interpreter context
The current sub, continuation, and object already have a storage in the
context structure and are accessible via the C opcode
that saving and restoring the top
register set isn't required
3) Get IMCC to skip the save/restore set
Ok.
and we see where we go from there. I'm not inclined, yet, to drop the
register stacks and the push/pop ops as there are certainly times when
it's useful, being a quick way to sp
On Oct 21, 2004, at 8:34 AM, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like
to do with the interpreter, the register frame, and the register
backing stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date now
mplement the new indirect register frame
2) Note in the calling conventions that saving and restoring the top
register set isn't required
3) Get IMCC to skip the save/restore set
and we see where we go from there. I'm not inclined, yet, to drop the
register stacks and the push/pop ops
I almost forgot: there is F in CVS, which shows both
the current and a possible future register layout (-DINDIRECT). You can
time the normal function calling core with the mops benchmark by
compiling it with -DMOPS.
Have fun,
leo
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like to
do with the interpreter, the register frame, and the register backing
stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date now that is: it doesn't do any absolute register
addre
turn values get copied as well as the
interpreter context. Its basically the same as was in, until around
0.0.3, except that we had 4 register frame pointers and 4 stacks. I
really want to have just one register frame pointer now. It avoids 3/4th
of the stack push/pop overhead and mappes nicely to run l
On Oct 20, 2004, at 12:09 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok, shor
At 9:09 PM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing
the registers from out of the interpreter structure, which'd leave
us needing two pointers, one for the interpreter struct and one for
the registers.
Ok, short s
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok, short summary of future layout of JIT regs:
item
e not saving much on the register stacks (and with the
switch in calls we won't be, which means we can drop the
pushtop/poptop stuff on calls) it's easier to go with a
one-frame-per-chunk setup.
Yep, it's easier. Let's start with that.
Good. Today I can manage eaiser. I'
Dan Sugalski wrote:
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Right. Any time an actual continuation is created we need to walk back
up the call chain and mark all the pending return continuations as
non-recyclable.
Ok.
If we're not saving much on the register stacks (and wit
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The first is the CPS style chews through continuation objects at a
massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk alrea
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The first is the CPS style chews through continuation objects at a
> massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk already.
> A return continuation is a *pot
[EMAIL PROTECTED] wrote:
Could we have the chunks only hold one frame and avoid much of the
compaction work? If we return to the inderict access mechanism, we
can switch register frames by changing one pointer. But if we keep
the one frame per chunk, we do not need to compact frames, standard
DOD
f its continuation-ness can be deferred. That
is, unless something takes a real continuation or fetches the return
continuation out of the return continuation register (thus turning it
from potential to actual) the continuation can be safely recycled
once invoked and doesn't have to go CO
Leo~
Thanks for the detailed explanation.
On Tue, 19 Oct 2004 10:50:22 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Until around Parrot 0.0.3 there were chunked stacks *with* an
> indirection for the register frame pointers. During development of the
> JIT system these i
rrently done by copying onto the
frame stacks. After function return there's another copy going on to
restore registers.
Until around Parrot 0.0.3 there were chunked stacks *with* an
indirection for the register frame pointers. During development of the
JIT system these indirections got dropped
n't start by me forgetting to fix Reply-To when trying to
> post follow-up on the list. ;)
>
> Essentially we whipped up a GC scheme for collecting the register stacks
> that doesn't make call/cc-using code, well, unusably slow.
>
> In addition to LT's origi
This is a summary of a private mail conversation between Leo and myself.
No, it didn't start by me forgetting to fix Reply-To when trying to
post follow-up on the list. ;)
Essentially we whipped up a GC scheme for collecting the register stacks
that doesn't make call/cc-using
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Didn't get much response
... so I'm responding to myself ;)
I've checked in docs/nanoparrot.c. While it should be a document
showing, how the interpreter actually performs its work, it also allows
comparison of the additional performance penalty of the
Didn't get much response last time I came up with this. But as we really
have to improve calling speed, here is again the original text. Below
are some additional remarks.
Original Message
Subject: Register stacks again
Date: Sat, 08 May 2004 13:29:20 +0200
From: Le
Leopold Toetsch writes:
> [1] yes I'm thinking of just one frame pointer :) Well, the whole scheme
> makes a stack machine out of Parrot:
>
> I0,...In, In+1Ik, Ik+1...Il
> ^
> |
> frame
> pointer
>
> I0..In are the incoming function arguments
> In+1..Ik are the working registers of the funct
For reference Dan's blog entry at:
http://www.sidhe.org/~dan/blog/archives/000321.html
I think that the situation has changed again and that we should consider
the original register in the stack scheme.
1) In the presence of MMD and delegate functions, object acessor methods
and OO in general, w
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 8:46 AM +0100 3/23/04, Leopold Toetsch wrote:
>>Piers Cawley <[EMAIL PROTECTED]> wrote:
>>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
> And what control stack? The continuation chain is the control
> stack, surely?
Nope. There's t
Leopold Toetsch wrote:
Matt Fowles <[EMAIL PROTECTED]> wrote:
... Why not just make exception handlers a second
continuation passed to all functions.
... because it is answered in a f'up to a similar proposal by our
summarizer:
,--[ leo ]---
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> This got warnocked
Only indirectly ...
> ... Why not just make exception handlers a second
> continuation passed to all functions.
... because it is answered in a f'up to a similar proposal by our
summarizer:
,--[ leo ]--
OW-ing
*anything* with the stack.
BTW: which stacks: Register frames of course. What about Pad, User,
and
Control?
I hope he means "All of 'em".
And what control stack? The continuation chain is the control stack,
surely?
Nope. There's the exception handlers, at the v
We should be careful not to use up too many PMC registers.
But the current lexical pad structures are suboptimal (searching is
O(n)). OTOH we need some kind of linked lists of pads, which matches the
single item stacks approach.
Just because the current ver
res the pad
> register and away you go.
Interesting idea. Well, the control register is a pointer in the context
structure. We should be careful not to use up too many PMC registers.
But the current lexical pad structures are suboptimal (searching is
O(n)). OTOH we need some kind of linked lists of pads, which matches the
single item stacks approach.
leo
t;>>> frame stack chunk then we don't have to bother with COW-ing
>>>> *anything* with the stack.
>>>
>>> BTW: which stacks: Register frames of course. What about Pad, User, and
>>> Control?
>>
>>I hope he means "All of 'em".
>
:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... If we go with a one
frame stack chunk then we don't have to bother with COW-ing
*anything* with the stack.
BTW: which stacks: Register frames of course. What about Pad, User, and
Con
At 12:59 AM + 3/23/04, Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... If we go with a one
frame stack chunk then we don't have to bother with COW-ing
*anything* with the stack.
BTW: which stacks: Register
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> ... If we go with a one
>> frame stack chunk then we don't have to bother with COW-ing
>> *anything* with the stack.
>
> BTW: which stacks: Register frames of
At 8:33 PM +0100 3/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:
D'oh! (I should edit this all out but, well...) If we go with a one
frame stack chunk then we don't have to bother with COW-ing
*anything* with the stack. W
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:00 PM +0100 3/22/04, Leopold Toetsch wrote:
> D'oh! (I should edit this all out but, well...) If we go with a one
> frame stack chunk then we don't have to bother with COW-ing
> *anything* with the stack. Which makes the differentiation between a
> re
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... If we go with a one
> frame stack chunk then we don't have to bother with COW-ing
> *anything* with the stack.
BTW: which stacks: Register frames of course. What about Pad, User, and
Control?
leo
which the continuation should run
3) Mark the stacks as COW
Step 3 is universally required *however* we can skip it *if* we
mandate that return continuations can't be used for anything other
than returning. I'm not sure that's a good idea, but we can do it. We
can also do it tran
run
> 3) Mark the stacks as COW
> Step 3 is universally required *however* we can skip it *if* we
> mandate that return continuations can't be used for anything other
> than returning. I'm not sure that's a good idea, but we can do it. We
> can also do it transparently
d a more unified solution.
Making a continuation conceptually has three steps. One must:
1) Copy the current environment contents to the continuation
2) Note the bytecode address at which the continuation should run
3) Mark the stacks as COW
Step 3 is universally required *however* we can skip it *if
I've checked in a bunch of changes WRT stack code:
* register frames and pad, user, control - stacks have now common
code to handle new, push, pop, and copy
* COW copying is now implemented (hopefully) correctly for all stacks
This should also make the GC-related memory corruption vanish.
leo
n't think this is hurting us. If there's another copy, it's
> in a continuation.
We got that problem on *all* stacks, not only register frames used in
Continuations.
> Luke
leo
Luke Palmer writes:
>
> -memcpy(buf->data.bufstart, chunk->data.bufstart, stack->chunk_size);
> +memcpy(buf->data.bufstart, chunk->data.bufstart,
> +stack->frame_size * FRAMES_PER_CHUNK);
Silly me -- left over from benchmarks. Of course I mean:
+ memcpy(buf->data.buf
Leopold Toetsch writes:
> Luke Palmer clearly should, that optimizations WRT register frame stacks
> are possible.
> The follwing numbers seem to second that:
>
> FRAMES_PER_CHUNK time real user
> 4 1.2s 0.9
> 8 1.6
>
Luke Palmer clearly should, that optimizations WRT register frame stacks
are possible.
The follwing numbers seem to second that:
FRAMES_PER_CHUNK time real user
4 1.2s0.9
8 1.6
16 2.3 1.4
These are runs of
parrot -j -Oc
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Unifying the user and control stacks make sense. I don't see any
> point in unifying the pad stack with anything, since it's not really
> a stack as such, or at least ought not be, and it's got a more
> complex linking
ne arena. With the register frames in place, we would
have at least 2 more arenas with (1024+x) and (2048+x) bytes for x=12
currently (32-bit systems).
And the question is: should we unify other stacks (Pad, User, Control)
with the register frame stacks? stacks.c's implementation has
additio
#x27;re already walking the stack frame areas, so I'm not
> sure it'll work out that way.
Yes. But only one arena. With the register frames in place, we would
have at least 2 more arenas with (1024+x) and (2048+x) bytes for x=12
currently (32-bit systems).
And the question is: should
At 5:47 PM +0100 1/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: "used")
struct hunk *upchain;
struct regframe RegisterFram
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> struct hunk {
> struct pobj header;
> INTVAL used;
> INTVAL avail;
Only one of these is needed (and currently used: "used")
> struct hunk *upchain;
> struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have t
At 1:02 AM -0500 1/9/04, Michal Wallace wrote:
I changed my compiler to call savetop before every function
call, and that passes my tests but I'm having trouble
visualizing why. Would I ever NOT want to call savetop
before creating a continuation?
Sure. The only reason to call savetop is if you wan
Picking the last entry in this thread to reply to...
Here's the scoop with register stacks, stacks in general, and continuations.
The pointers to all these stack tops *should* be part of a
continuation, the same as the registers themselves should be. When a
continuation is taken, al
Luke Palmer <[EMAIL PROTECTED]> wrote:
> This patch re-implements the register backing stacks as PObjs (so they
> can be garbage-collected), honors their COW flags, and adds them to the
> interpreter context (where they should be, honest!).
> As a healthy side-effect, it
On Fri, 9 Jan 2004, Luke Palmer wrote:
> Very rarely would you not savetop before creating a *real* continuation.
> But again, very rarely would you actually create a *real* continuation
> (depending on your language). RetContinuations are almost always a
> better choice for traditional languages
On Fri, 9 Jan 2004, Leopold Toetsch wrote:
> Michal Wallace <[EMAIL PROTECTED]> wrote:
>
> > newsub $P1, .Continuation, done
>
> For returning just use a .RetContinuation. Or still better, just omit
> $P1 totally here:
>
> > .pcc_call $P0, $P1
Aha! I like that even better. :) Thanks!
Sin
Michal Wallace writes:
> On Thu, 8 Jan 2004, Luke Palmer wrote:
> > .sub __main__
> > newsub $P0, .Closure, _func
> > savetop
> > newsub $P0, .Continuation, done
> >
> > So the restoretop after the invoke has something to pop (and so your
> > register state isn't screwed up when you get
Michal Wallace <[EMAIL PROTECTED]> wrote:
> newsub $P1, .Continuation, done
For returning just use a .RetContinuation. Or still better, just omit
$P1 totally here:
> .pcc_call $P0, $P1
leo
Luke Palmer <[EMAIL PROTECTED]> wrote:
> .sub __main__
> newsub $P0, .Closure, _func
> savetop
No - not for plain subroutines/closures.
> Or you could do as PCC does and use a .RetContinuation, which doesn't
> close over the stacks, when you don't actually
On Thu, 8 Jan 2004, Luke Palmer wrote:
> @pcc_sub_call_4:
> set P0, P17
> set P1, P16
> set I0, 0
> set I1, 0
> set I2, 0
> set I3, -2
> updatecc
> savetop
> invoke
> done:
> restoretop
> set P16, P5
>
> When t
Michal Wallace writes:
> Luke Palmer wrote:
>
> > This patch re-implements the register backing stacks as PObjs (so
> > they can be garbage-collected), honors their COW flags, and adds
> > them to the interpreter context (where they should be, honest!).
> >
&g
Luke Palmer wrote:
> This patch re-implements the register backing stacks as PObjs (so
> they can be garbage-collected), honors their COW flags, and adds
> them to the interpreter context (where they should be, honest!).
>
> As a healthy side-effect, it encapsulates their behav
On Jan 8, 2004, at 4:24 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
I think I'm just being dense, but looking at
include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themse
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I think I'm just being dense, but looking at
> include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themselves, which went out of the context.
leo
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> This patch sets up a generic register stack (using macro's for values
> that change) that the real register stacks can then implement. This was
> discussed on list several months ago, but nobody ever got around to it.
>
t change) that the real register stacks can then implement. This was
discussed on list several months ago, but nobody ever got around to it.
So I did ;-)
I am not entirely certain how to fix the manifest, but I did try...
Other than that all tests pass for make test and make testj. make test
t change) that the real register stacks can then implement. This was
discussed on list several months ago, but nobody ever got around to it.
So I did ;-)
I am not entirely certain how to fix the manifest, but I did try...
Other than that all tests pass for make test and make testj. make test
On Jan 7, 2004, at 8:15 PM, Melvin Smith wrote:
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> Exactly the latter:
> That was AFAIK a design decision, when Dan did introduce CPS. At
this
> time regi
part is already answered: create a buffer_like structure.
>> > >> *But* again register backing stacks are *not* in the interpreter
>> > >> context.
>> >
>> > > I don't understand what you are getting at. They are not physically
>> > >
> path will return using that continuation, and that will then become
> the "main" execution context. The original interpreter context and
> all its associated stacks that existed at the time of the snapshot
> will usually immediately be readonly orphans as soon as you activate
At 06:37 PM 1/7/2004 -0700, Luke Palmer wrote:
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> >> That part is already answered: create a buffer_like structure.
> >> *But* again registe
This patch re-implements the register backing stacks as PObjs (so they
can be garbage-collected), honors their COW flags, and adds them to the
interpreter context (where they should be, honest!).
As a healthy side-effect, it encapsulates their behavior nicely into
register.c, when before their
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> >> That part is already answered: create a buffer_like structure.
> >> *But* again register backing stacks are *not* in the interpreter
> &
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
>> That part is already answered: create a buffer_like structure.
>> *But* again register backing stacks are *not* in the interpreter
>> context.
> I don't understand wh
.
*But* again register backing stacks are *not* in the interpreter
context.
I don't understand what you are getting at. They are not physically
part of Parrot_Interp.ctx, but it holds pointers to them, right? So,
they need to be copied when the context is being duplicated. Is that
your point,
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It makes each chunk into a subclass of Buffer like so:
> struct RegisterChunkBuf {
> size_t used;
> PObj* next;
> };
That part is already answered: create a buffer_like structure.
*But* again register backin
On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:
Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
To do that properly, I think you need a pobj_t as the
e typically the execution
path will return using that continuation, and that will then become
the "main" execution context. The original interpreter context and
all its associated stacks that existed at the time of the snapshot
will usually immediately be readonly orphans as soon as you activat
Jeff Clites writes:
> On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
>
> >Leopold Toetsch writes:
> >>
> >>Good. Pass it over to me :) COW copy of stacks and of other
> >>buffer-based
> >>items is still broken. These need distinct headers so that
1 - 100 of 231 matches
Mail list logo
