Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

From the "Interesting, but is it useful?" department

8 views
Skip to first unread message

Melvin Smith

unread,
Nov 3, 2003, 12:28:56 PM11/3/03
to perl6-i...@perl.org, dan Sugalski
I've been playing with an "uncommitted" op version of invoke
that takes a method or sub by name like below:

invoke "foo", 0

The 0 is irrelevant to the eye, but it is a placeholder for the self-modifying
instruction. Upon call, invoke by name does:

op invoke(STR, INT)
PMC sub
if($2 == 0) {
sub = lookup $1
$2 = sub # store the ref in the immediate data of the instruction
}
else {
sub = (PMC*)$2
}
sub->vtable->invoke()
}

Basically it is just caching the lookup into the immediate data portion
of the bytecode instruction.

It isn't really anything new, this has been done before in VMs, but
the problem becomes the PMC that is stored in the bytecode is unknown
to the GC/DOD. Easy enough to fix, rather than store the PMC * itself,
simply keep a method_cache[] that the DOD can traverse, and store
only the array slot in the bytecode.

Maybe this is only syntactic sugar, I don't know.

The case is a win for loops that call the same method.

P0 = find_method "foo" # Lookup by name
LOOP:
invoke P0
if something goto LOOP

becomes:

LOOP
invoke "foo" # Lookup by name only the 1st execution
if something goto LOOP


There is no register usage for the method PMC.

Already, we are going to have a method_cache[] structure, so it follows
that we could allow for this shortcut simply to hide the cache for some
cases. This shortcut has the same challenges as the non-shortcut with
notifiying/invalidating PMC method references, so the same solutions apply.

The other question is: does this little trick apply to other things that do
lookups by name with constant strings?

-Melvin


Leopold Toetsch

unread,
Nov 4, 2003, 2:32:40 AM11/4/03
to Melvin Smith, perl6-i...@perl.org
Melvin Smith <mrjol...@mindspring.com> wrote:

> op invoke(STR, INT)
> PMC sub
> if($2 == 0) {
> sub = lookup $1
> $2 = sub # store the ref in the immediate data of the instruction

This doesn't really work:
- byte-code is readonly, if mmap()ed and when running function core or
CGoto
- for prederefed cores, the assign instruction needs predereferencing
- doesn't work with JIT
- There is no means to invalidate the sub, when something changed.

> The other question is: does this little trick apply to other things that do
> lookups by name with constant strings?

These lookups are in C-code mostly, so no.

> -Melvin

leo

Melvin Smith

unread,
Nov 4, 2003, 3:27:19 AM11/4/03
to l...@toetsch.at, perl6-i...@perl.org
At 08:32 AM 11/4/2003 +0100, Leopold Toetsch wrote:
>Melvin Smith <mrjol...@mindspring.com> wrote:
>
> > op invoke(STR, INT)
> > PMC sub
> > if($2 == 0) {
> > sub = lookup $1
> > $2 = sub # store the ref in the immediate data of the instruction
>
>This doesn't really work:
>- byte-code is readonly, if mmap()ed and when running function core or
> CGoto

It doesn't have to be. Neither mmap() nor computed goto requires
the bytecode to be readonly. Also it should be possible to execute
readonly bytecode and detect when we are doing so.

>- for prederefed cores, the assign instruction needs predereferencing
>- doesn't work with JIT

True.

>- There is no means to invalidate the sub, when something changed.

See the other comment in the original message where I mentioned
storing a "slot" number instead of the PMC itself. The slot can be
a pointer to a method cache. A method cache can be known to
the GC.

Also, invalidating PMCs can happen via event queues so it doesn't
really matter where the PMC is stored.

That aside, I still think it is not worth committing since it is only
a syntactical shortcut, and may actually obfuscate things.

-Melvin


Leopold Toetsch

unread,
Nov 4, 2003, 5:31:48 AM11/4/03
to Melvin Smith, perl6-i...@perl.org
Melvin Smith <mrjol...@mindspring.com> wrote:
> At 08:32 AM 11/4/2003 +0100, Leopold Toetsch wrote:
>>Melvin Smith <mrjol...@mindspring.com> wrote:
>>
>> > $2 = sub # store the ref in the immediate data of the instruction
>>
>>This doesn't really work:
>>- byte-code is readonly, if mmap()ed and when running function core or
>> CGoto

> It doesn't have to be. Neither mmap() nor computed goto requires
> the bytecode to be readonly.

Readonly code segments and multi-threading are the keywords here.

Function core and CGoto of course don't require the code to be readonly,
but for these cores the code is executed from a mmap()ed piece of memory,
which really should be sharable.

leo

Dan Sugalski

unread,
Nov 4, 2003, 9:02:04 AM11/4/03
to Melvin Smith, l...@toetsch.at, perl6-i...@perl.org
On Tue, 4 Nov 2003, Melvin Smith wrote:

> At 08:32 AM 11/4/2003 +0100, Leopold Toetsch wrote:
> >Melvin Smith <mrjol...@mindspring.com> wrote:
> >
> > > op invoke(STR, INT)
> > > PMC sub
> > > if($2 == 0) {
> > > sub = lookup $1
> > > $2 = sub # store the ref in the immediate data of the instruction
> >
> >This doesn't really work:
> >- byte-code is readonly, if mmap()ed and when running function core or
> > CGoto
>
> It doesn't have to be. Neither mmap() nor computed goto requires
> the bytecode to be readonly. Also it should be possible to execute
> readonly bytecode and detect when we are doing so.

Right, but I do. (As does threading) There are better ways to do method
caches, I think.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

0 new messages