Re: Events and JIT
On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote: Jeff Clites <[EMAIL PROTECTED]> wrote: Where in the stream would we patch? If not in a loop, you may never hit the single patched location again, but still might not end for a very long time Same as with prederefed run cores: backward branches, invoke* What I meant was, _every_ backward branch (etc.) in the bytecode, or just one location that we thought would execute "soon". (But you implicitly answered this, below.) If we are patching all locations with branches and such, in large bytecode this could take a long time, and the executing thread might outrun the "patching" thread. We have of course to benchmark this scheme against other approaches. Albeit finding/writing such benchmarks and measuring responsiveness will be some fun ;) But we can of course measure how long it takes to patch a certain amount of code twice. It just seems bad that the efficiency of event delivery would be proportional to the size of the bytecode (or segment). So it's slower to deliver events in large programs. That seems like a bad omen. ... Also, once the handler is entered we'd have to fix all of patched locations, which again could be time-consuming for large bytecode. Please remember: only the current code segment has to be patched, which theoretically could be very large, but that's unlikely. I don't think that's correct--the thread to which we are trying to deliver the event could have branched to a new segment before we finished patching. JEff
Re: JVM as a threading example (threads proposal)
On Jan 17, 2004, at 2:58 AM, Leopold Toetsch wrote: Damien Neil <[EMAIL PROTECTED]> wrote: The JVM is a stack machine. JVM opcodes operate on the stack, not on main memory. The stack is thread-local. In order for a thread to operate on a variable, therefore, it must first copy it from main store to thread- local store (the stack). Silly me, yes of course, that's it. Parrot, so far as I know, operates in exactly the same way, except that the thread-local store is a set of registers rather than a stack. Except that we don't need this mulit-step variable access, because a P-register can refer to a shared PMC living in a different thread, which is a different threads interpreter->arena_base memory. But just like a P-register, a Java stack entry can hold a reference to an object, and in Java there's no thread-based ownership if objects. So if this parallel is correct, then Java wouldn't need 2-step access either. This is part of why I think this is the wrong interpretation of the JVM spec. JEff
Re: Problem during "make test"
On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote: > I've converted this exit() to Parrot_exit() now. If that helps, I'll > change a bunch of other such code too. Yep, that fixed. Now there are hangs in some of the t/src files. Right now, it's t/src/sprintf.t at test 2. The backtrace looks familiar: (gdb) bac #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x0ff973e0 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x0ff96fe4 in pthread_onexit_process () from /lib/libpthread.so.0 #3 0x0fd0a694 in exit () from /lib/libc.so.6 #4 0x0fcf23a8 in __libc_start_main () from /lib/libc.so.6 I saw something similar in t/src/extend.t as well. Otherwise, everything passes. Perhaps a Parrot_cleanup() would help extenders and embedders? -- c
Re: [PATCH] Fix imcpasm tests on Win32
Leopold Toetsch wrote: Jonathan Worthington <[EMAIL PROTECTED]> wrote: The attached patch fixes a problem in imcc/TestCompiler.pm which was causing all imcpasm tests to fail on Win32. Applied, as well as the icu.pl patch. [ Please provide patches relative to parrot root to simplify applying ] Do you mean we should be using: cvs -Q diff -c > patchfile.txt when creating our patches rather than just diff'ing two files and then sending them with [PATCH] in the subject. Harry
Re: Events and JIT
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote: Gordon Henriksen <[EMAIL PROTECTED]> wrote: What if control leaves the current code segment before you finish patching it? Ops that can leave the code segment have to explicitely check for events. Then no need to patch invoke*. If the target thread handles the event and unpatches the bytecode before the source thread finishes patching? — Gordon Henriksen [EMAIL PROTECTED]
Re: [perl #24930] [PATCH] Correct Parrot_readbc prototype
Mattia Barbon <[EMAIL PROTECTED]> wrote: > with this patch calling Parrot_redabc(interp, "foo") does not > warn anymore. Thanks, applied > Mattia leo
Re: CVS troubles
Arvindh Rajesh Tamilmani <[EMAIL PROTECTED]> wrote: > do > $ cvs update -A classes/timer.pmc > to remove the "sticky tag" and try committing again. Ah, yes thanks, that worked. > HTH, > arvindh. leo
Re: Events and JIT
Gordon Henriksen <[EMAIL PROTECTED]> wrote: > What if control leaves the current code segment before you finish=20 > patching it? If an event is being delivered from another thread, this is=20= Ops, that can leave the code segment have to explicitely check for events. > Gordon Henriksen leo
Re: Optimization brainstorm: variable clusters
On Sat, Jan 17, 2004 at 04:58:25PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Dave Mitchell) writes: > > The perl5 internals are a complete mess. It's like Jenga - to get the > > perl5 tower taller and do something new you select a block somewhere in > > the middle, with trepidation pull it out slowly, and then carefully > > balance it somewhere new, hoping the whole edifice won't collapse as a > > result. > > - Nicholas Clark. > > I thought I'd seen that before: http://www.oreillynet.com/pub/wlg/555 Oooh, plagiarism! Sue sue sue! I'll update the attribution for future .sigs. -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. -- Larry Wall
Re: Optimization brainstorm: variable clusters
[EMAIL PROTECTED] (Dave Mitchell) writes: > The perl5 internals are a complete mess. It's like Jenga - to get the > perl5 tower taller and do something new you select a block somewhere in > the middle, with trepidation pull it out slowly, and then carefully > balance it somewhere new, hoping the whole edifice won't collapse as a > result. > - Nicholas Clark. I thought I'd seen that before: http://www.oreillynet.com/pub/wlg/555 -- Life's a switch() and then you die().
Re: cygwin link failure
On Friday, January 16, 2004, at 03:34 , Seiler Thomas wrote: inet_pton has not yet been implemented in cygwin, but it is being worked on... http://win6.jp/Cygwin/ Indeed, but I think there might be other unix-like environments that (do not yet|will never) provide the inet_pton function. Mac OS X 10.1 does not. — Gordon Henriksen [EMAIL PROTECTED]
Re: Events and JIT
On Saturday, January 17, 2004, at 05:51 , Leopold Toetsch wrote: Jeff Clites <[EMAIL PROTECTED]> wrote: ... Also, once the handler is entered we'd have to fix all of patched locations, which again could be time-consuming for large bytecode. Please remember: only the current code segment has to be patched, which theoretically could be very large, but that's unlikely. What if control leaves the current code segment before you finish patching it? If an event is being delivered from another thread, this is very likely to occur if the event delivery thread is preempted by the event receiver. — Gordon Henriksen [EMAIL PROTECTED]
Re: Events and JIT
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote: Gordon Henriksen <[EMAIL PROTECTED]> wrote: Other threads than the target could be executing the same chunk of JITted code at the same time. No. JITed (and prederefed) code is thread-specific, because register addresses are converted to absolute memory locations. Ack! Might want that to be configurable for the JIT, to reduce the overhead of starting a thread... — Gordon Henriksen [EMAIL PROTECTED]
RE: CVS troubles (was: IMCC v1 call for bug list and feature freeze)
>cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is >not a branch do $ cvs update -A classes/timer.pmc to remove the "sticky tag" and try committing again. The sticky tag gets set when cvs checkout/update is done with the -r option. >leo HTH, arvindh. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
[perl #24931] [PATCH] Win32 MinGW build fixes
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24931]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24931 >
Hello,
the important part is the change to config/init/hints/mswin32.pl,
without which the build fails.
The other changes are just warning fixes.
Tested with GCC 3.3 (and 3.2 and 2.95) with GNU make 3.79
Regards
Mattia
? t/pmc/coroutine_4.imc
Index: config/gen/platform/win32.h
===
RCS file: /cvs/public/parrot/config/gen/platform/win32.h,v
retrieving revision 1.9
diff -u -2 -r1.9 win32.h
--- config/gen/platform/win32.h 25 Nov 2003 16:23:06 - 1.9
+++ config/gen/platform/win32.h 17 Jan 2004 13:53:25 -
@@ -21,4 +21,5 @@
void Parrot_platform_init_code(void);
+#ifdef _MSC_VER
/* These disable certain Level 4 Warnings */
#pragma warning( disable: 4100 ) /* disables 'unreferenced formal parameter'
@@ -29,4 +30,6 @@
#pragma warning( disable: 4505 ) /* disables 'unreferenced local function has
* been removed' warnings in header files */
+#endif /* defined(_MSC_VER) */
+
/*
** Miscellaneous:
Index: config/init/hints/mswin32.pl
===
RCS file: /cvs/public/parrot/config/init/hints/mswin32.pl,v
retrieving revision 1.17
diff -u -2 -r1.17 mswin32.pl
--- config/init/hints/mswin32.pl22 Nov 2003 09:55:45 - 1.17
+++ config/init/hints/mswin32.pl17 Jan 2004 13:53:26 -
@@ -103,5 +103,5 @@
link => 'gcc',
libs => $libs,
- slash => '\\',
+ slash => '/',
ar=> 'ar',
);
Index: src/hash.c
===
RCS file: /cvs/public/parrot/src/hash.c,v
retrieving revision 1.68
diff -u -2 -r1.68 hash.c
--- src/hash.c 15 Jan 2004 21:50:24 - 1.68
+++ src/hash.c 17 Jan 2004 13:53:41 -
@@ -739,4 +739,5 @@
internal_exception(-1, "hash corruption: type = %d\n",
hash->entry_type);
+valtmp = NULL; /* avoid warning */
};
hash_put(interp, *dest, key, valtmp);
Index: src/spf_render.c
===
RCS file: /cvs/public/parrot/src/spf_render.c,v
retrieving revision 1.28
diff -u -2 -r1.28 spf_render.c
--- src/spf_render.c6 Jan 2004 17:13:32 - 1.28
+++ src/spf_render.c17 Jan 2004 13:53:44 -
@@ -604,10 +604,10 @@
if(tolower(ch) == 'g') {
-UINTVAL i;
-for(i=0; i < strlen(tc); i++) {
-if(tolower(tc[i]) == 'e' &&
-(tc[i+1] == '+' || tc[i+1] == '-')) {
-tc[i+2]='\0';
-strcat(tc, &(tc[i+3]));
+UINTVAL j;
+for(j=0; j < strlen(tc); j++) {
+if(tolower(tc[j]) == 'e' &&
+(tc[j+1] == '+' || tc[j+1] == '-')) {
+tc[j+2]='\0';
+strcat(tc, &(tc[j+3]));
}
}
Index: src/thread.c
===
RCS file: /cvs/public/parrot/src/thread.c,v
retrieving revision 1.15
diff -u -2 -r1.15 thread.c
--- src/thread.c14 Jan 2004 13:10:13 - 1.15
+++ src/thread.c17 Jan 2004 13:53:45 -
@@ -224,5 +224,5 @@
if (interpreter->thread_data->state == THREAD_STATE_JOINABLE ||
interpreter->thread_data->state == THREAD_STATE_FINISHED) {
-void *retval;
+void *retval = NULL;
interpreter->thread_data->state |= THREAD_STATE_JOINED;
UNLOCK(interpreter_array_mutex);
[perl #24930] [PATCH] Correct Parrot_readbc prototype
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24930]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24930 >
Hello,
with this patch calling Parrot_redabc(interp, "foo") does not
warn anymore.
Regards
Mattia
Index: include/parrot/embed.h
===
RCS file: /cvs/public/parrot/include/parrot/embed.h,v
retrieving revision 1.22
diff -u -2 -r1.22 embed.h
--- include/parrot/embed.h 13 Dec 2003 15:01:15 - 1.22
+++ include/parrot/embed.h 17 Jan 2004 13:53:33 -
@@ -34,5 +34,5 @@
void Parrot_setwarnings(Parrot_Interp, Parrot_warnclass);
-Parrot_PackFile Parrot_readbc(Parrot_Interp, char *);
+Parrot_PackFile Parrot_readbc(Parrot_Interp, const char *);
void Parrot_loadbc(Parrot_Interp, Parrot_PackFile);
Index: src/embed.c
===
RCS file: /cvs/public/parrot/src/embed.c,v
retrieving revision 1.98
diff -u -2 -r1.98 embed.c
--- src/embed.c 21 Dec 2003 10:15:19 - 1.98
+++ src/embed.c 17 Jan 2004 13:53:38 -
@@ -87,5 +87,5 @@
*/
struct PackFile *
-Parrot_readbc(struct Parrot_Interp *interpreter, char *filename)
+Parrot_readbc(struct Parrot_Interp *interpreter, const char *filename)
{
#if PARROT_HAS_HEADER_UNISTD
CVS troubles (was: IMCC v1 call for bug list and feature freeze)
Melvin Smith <[EMAIL PROTECTED]> wrote: > cvs checkout -r imcc1final parrot I don't know, if this is related, but I get now errors on commit: cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is not a branch I did commit some patches an hour before which worked fine. Now I suddenly get a bunch of these messages. What does it mean? $ cvs status -v classes/timer.pmc === File: timer.pmc Status: Locally Modified Working revision:1.10 Repository revision: 1.10/cvs/public/parrot/classes/timer.pmc,v Sticky Tag: HEAD (revision: 1.10) Sticky Date: (none) Sticky Options: (none) Existing Tags: imcc1final (branch: 1.10.2) RELEASE_0_0_13 (revision: 1.7) file_move_031023(revision: 1.7) RELEASE_0_0_11 (revision: 1.7) help(revision: 1.6) leo
Re: Optimization brainstorm: variable clusters
At 09:27 -0500 1/16/04, Dan Sugalski wrote:
To some extent, yes. I just had a really nasty thought, and I think
the compiler writers need to get Official Rulings on behavior.
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo > 10) {
print $foo;
}
will require fetching $foo's PMC out of the global namespace three
times, once for each usage. I don't know offhand if this is how perl
5 works (I think it might be) and we should check for perl 6,
python, and ruby. This is mainly because of the possibility of tied
or overridden namespaces, which would argue for a refetch on each
use.
*Not* refetching is a perfectly valid thing, and not specifying is
also perfectly valid, but we need to check.
sub Foo::TIESCALAR { bless \$_[1],$_[0] }
sub Foo::FETCH { warn "FETCH\n"; ${$_[0]} }
sub Foo::STORE { warn "STORE\n"; ${$_[0]} = $_[1] }
our $foo; # It's a global
tie $foo,'Foo',$foo:;
$foo = 12;
if ($foo > 10) {
print $foo;
}
__END__
STORE
FETCH
FETCH
12
Don't know why you thgink it would be fetched 3 times, but as using
tied variables in Perl 5, a fetch is done _everytime_ the value of
the tied variable is needed.
Liz
Re: [perl #24913] [PATCH] register.c code simplification
Matt Fowles <[EMAIL PROTECTED]> wrote: > This patch is similar in concept to the first one I sent; however, it is > based off of the new register.c. Thanks, applied. > I did not fix the manifest because I don't know how. So that needs to > be done. Its just inserting the filename in MANIFEST - done. > Matt leo
Re: Problem during "make test"
Chromatic <[EMAIL PROTECTED]> wrote: > This gets further. Now it's imcc/t/syn/macro, around tests 13 and 14: Good. > #3 0x0fd0a694 in exit () from /lib/libc.so.6 I've converted this exit() to Parrot_exit() now. If that helps, I'll change a bunch of other such code too. leo
Re: [FYI] Win32 SFU
On Fri, 16 Jan 2004 08:09:58 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: > I don't know, if we should depend on that, but it would definitely help. > Could some Windows guys have a look at: > http://www.microsoft.com/windows/sfu/ > > > [Interoperability. Integration. Extensibility.] > Windows Services for UNIX (SFU) 3.5 provides the tools and environment > that IT professionals and developers need to integrate Windows with UNIX > and Linux environments. > > > leo > For those interested in evaluating this (137MB) SDK, but who are put off by the need to register using .NET Passport (sign in virtual blood:) as I was, this http://download.microsoft.com/download/winntunx/Trial/7.0.1701.1/NT45XP/EN-US/SFU%203.0%20Final%20-%20Eval.exe will take you directly to the download. Nigel.
Re: [PATCH] Fix imcpasm tests on Win32
Jonathan Worthington <[EMAIL PROTECTED]> wrote: > The attached patch fixes a problem in imcc/TestCompiler.pm which was causing > all imcpasm tests to fail on Win32. Applied, as well as the icu.pl patch. [ Please provide patches relative to parrot root to simplify applying ] > Jonathan Thanks, leo
Re: Events and JIT
Gordon Henriksen <[EMAIL PROTECTED]> wrote: > Other threads than the target could be executing the same chunk > of JITted code at the same time. No. JITed (and prederefed) code is thread-specific, because register addresses are converted to absolute memory locations. leo
Re: JVM as a threading example (threads proposal)
Damien Neil <[EMAIL PROTECTED]> wrote: > The JVM is a stack machine. JVM opcodes operate on the stack, not on > main memory. The stack is thread-local. In order for a thread to operate > on a variable, therefore, it must first copy it from main store to thread- > local store (the stack). Silly me, yes of course, that's it. > Parrot, so far as I know, operates in exactly the same way, except that > the thread-local store is a set of registers rather than a stack. Except that we don't need this mulit-step variable access, because a P-register can refer to a shared PMC living in a different thread, which is a different threads interpreter->arena_base memory. leo
Re: Events and JIT
Jeff Clites <[EMAIL PROTECTED]> wrote: > Where in the stream would we patch? If not in a loop, you may never hit > the single patched location again, but still might not end for a very > long time Same as with prederefed run cores: backward branches, invoke* > If we are patching all locations with branches and such, in large > bytecode this could take a long time, and the executing thread might > outrun the "patching" thread. We have of course to benchmark this scheme against other approaches. Albeit finding/writing such benchmarks and measuring responsiveness will be some fun ;) But we can of course measure how long it takes to patch a certain amount of code twice. > ... Also, once the handler is entered we'd > have to fix all of patched locations, which again could be > time-consuming for large bytecode. Please remember: only the current code segment has to be patched, which theoretically could be very large, but that's unlikely. > JEff leo
Re: Optimization brainstorm: variable clusters
On Fri, Jan 16, 2004 at 09:27:57AM -0500, Dan Sugalski wrote:
> With perl, for example, it's distinctly possible that this:
>
> our $foo; # It's a global
> $foo = 12;
> if ($foo > 10) {
> print $foo;
> }
>
> will require fetching $foo's PMC out of the global namespace three
> times, once for each usage. I don't know offhand if this is how perl
> 5 works (I think it might be)
In Perl5, a pointer to the GV is cached in the GVSV op (or in the case of
threaded builds, in the pad (with an index into the pad stored in the op
(is that enough levels of parenthesis for you?))). So if the stashes were
tied, you'd be stuffed. There was a recent thread on p5p as to whether
tieing of stashes should be disallowed.
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark.
