Re: [PATCH] new header buflen
On Mon, 20 May 2002, Jason Gloudon wrote: > > The buflen of a new header was not always set to 0, which would cause SIGSEGVs > when parrot_reallocate tries to copy a non-zero length buffer with a bufstart > of NULL. This would happen when buffers get recycled. > > I don't know if new_pmc_header has the same problem, but it also does not > initialize the buffer length. > Applied, thanks.
[PATCH] new header buflen
The buflen of a new header was not always set to 0, which would cause SIGSEGVs when parrot_reallocate tries to copy a non-zero length buffer with a bufstart of NULL. This would happen when buffers get recycled. I don't know if new_pmc_header has the same problem, but it also does not initialize the buffer length. Index: resources.c === RCS file: /home/perlcvs/parrot/resources.c,v retrieving revision 1.56 diff -c -r1.56 resources.c *** resources.c 20 May 2002 16:16:01 - 1.56 --- resources.c 20 May 2002 23:06:31 - *** *** 279,284 --- 279,286 return_me->flags = 0; /* Don't let it point to garbage memory */ return_me->bufstart = NULL; + /* Use the right length */ + return_me->buflen = 0; /* Return it */ return return_me; } -- Jason Index: resources.c === RCS file: /home/perlcvs/parrot/resources.c,v retrieving revision 1.56 diff -c -r1.56 resources.c *** resources.c 20 May 2002 16:16:01 - 1.56 --- resources.c 20 May 2002 23:06:31 - *** *** 279,284 --- 279,286 return_me->flags = 0; /* Don't let it point to garbage memory */ return_me->bufstart = NULL; + /* Use the right length */ + return_me->buflen = 0; /* Return it */ return return_me; }
Re: PMC pdd's in
On Fri, May 17, Nicholas Clark wrote: > On Thu, May 16, 2002 at 08:37:32PM -0400, Dan Sugalski wrote: > > Pssst. Brent. Don't tell anyone, but ~0 *is* -1... :) > > $ perl -le 'print ~0' > 4294967295 > $ perl -le 'print -1' > -1 > > What language were we talking about? :-) $ perl -e 'printf "%d\n", ~0' -1 Um Michael -- Michael Fischer Happiness is a config option. [EMAIL PROTECTED]Recompile and be happy.
Re: Vtable Methods in Parrot
On Mon, 20 May 2002, Daniel Grunblatt wrote: > > On Mon, 20 May 2002, David M. Lloyd wrote: > > > What about subroutines? Are bsr & jsr the way it's gonna be or is there > > a rework in the works? > > docs/pdds/pdd03_calling_conventions.pod :) OK, I've looked it over but it doesn't say "Subroutines are called via bsr" or "Subroutines are called via vtable methods" or whatever. It seems just to talk about stack usage and so on. The regular expression PDD talks about using bsr to call into a regular expression. - D <[EMAIL PROTECTED]>
Re: Vtable Methods in Parrot
On Mon, 20 May 2002, David M. Lloyd wrote: > What about subroutines? Are bsr & jsr the way it's gonna be or is there > a rework in the works? docs/pdds/pdd03_calling_conventions.pod :)
Re: Hashtable+GC problems
Steve Fink wrote: > Is there some way to make the default be that things will not get > moved around, and allow routines to volunteer to have their guts > scrambled if they know how to handle it? A few random thoughts re buffers that don't wander around on their own: Create a new memory pool for immobile buffers (yes, we have a use for that flag at last) - I don't think we need different resource pools Immobile memory pools would have a new type of compactor function, that would maintain a linked list of free space (I suspect this would require multiple passes) Allocation would occur using one of the old-fashioned algorithms like first-fit This scheme may use more memory than copy-collection, due to fragmentation, and would obviously be slower for memory allocation, since it has to traverse a list of free blocks. In effect, it would be equivalent to using the operating system's memory allocation routine, except that we still retain GC control over it. However, being more expensive than the current Parrot allocation scheme may still be cheaper than a different homegrown solution every time somebody needs a buffer to stay put - the idea would be to use immobile buffers only when no more elegant solution is available for a specific problem, rather than have them as the default - most buffers should not be location sensitive? Alternatively, we say that buffers are, by definition, not location sensitive. Then we force the use of PMCs in those situations, and re-implement the original concept of telling a PMC to move its data to a new location. That would require scanning PMCs during memory pool compaction - at which point we are pretty close to unification of buffers and PMCs anyway?? Comments? -- Peter Gibbs EmKel Systems
Re: Vtable Methods in Parrot
On Mon, 20 May 2002, David M. Lloyd wrote: > Has anyone given any thought to this problem yet? > > Will we be able to do this or do we need a special vtable whose entries > automatically do a callback to Parrot? For that matter, what about calling C functions from Parrot? Loading PMCs dynamically? Creating new PMC types from opcodes? Is it too early to start working on this stuff? What about subroutines? Are bsr & jsr the way it's gonna be or is there a rework in the works? - D <[EMAIL PROTECTED]>
Re: Hashtable+GC problems
On Sun, May 19, 2002 at 10:43:20PM -0400, Mike Lambert wrote: > I started to look into the GC crashes with the perlhash tests. I'm not > sure I found the exact problem, but I found a bunch of dangerous things > that were being done, and could possibly cause the GC problems. > > restore_invariants is an ugly hack that is prone to error. You have to > remember to restore_invariants after *any* header retrieval or memory > allocation, or anything that could cause that. For example, take > hash_delete. It restores invariants properly at the start of the > procedure. But if you'll notice down below in the body, it uses > string_compare. Due to transcoding issues, that can trigger a full GC, > which means you need to restore_invariants inside that loop. And that > invalidates your 'chain' which you've already placed on the local C stack, > and restore_invariants can't fix that. > > Same thing with hash_put, which calls find_bucket, which also calls > string_compare, with all the same problems. And same deal with hash_get, > which calls hash_lookup, which calls find_bucket, etc. > > I think you should go for an index-based approach to the hashtable > problem, to make this work nice and easily. If your concerned about code > clarity, I'd be happy to try and go in and attempt to clean things up. > Probably just needs a little macro usage to abstract out your hashtable > futzoring. (Just one level of macros, no need to worry. ;) Damn. Yep, you're right. I was mistakenly thinking I could get away with read-only access. But as you point out, doing anything with STRINGs can trigger allocations (and therefore collections.) Ok, I'll finish off the original conversion to indexed access that I began once, before giving up in disgust. The problem is not just that you have to use indices instead of pointers; it's also that you have to constantly go back to the buffer header before you can get anywhere. That needs to be hidden by a macro or (my preference) an inline function, and slows down the common case. Also, you lose the clean sentinel value NULL (index 0 is definitely valid; index -1 introduces signedness problems.) Let me know if you've already started a rewrite, though, so I don't just redo it. Something about the whole setup just feels wrong. GC shouldn't be this intrusive. And it definitely shouldn't slow down the common case by making the compiler defensively reload a buffer pointer every few instructions (it'll be cached, but it fouls up reordering.) Is there some way to make the default be that things will not get moved around, and allow routines to volunteer to have their guts scrambled if they know how to handle it? Or coming from a completely different direction, do it through exception handling and restartable atomic sequences: if something runs out of memory during its execution it throws an exception. The caller would then do the GC and retry the routine. As with any other exception, the routine has to be able to restore itself to a consistent state in the presence of an exception. (Or in other words: it's complicated, but we'll already be paying most of the price by supporting exceptions.)
Re: [PATCH] old packfile patch
On Mon, 20 May 2002, Jason Gloudon wrote: > > The disassembler isn't happy at the moment, this patch appears to fix > the problem it has with the bytecode header. > Applied, thanks.
Re: More memory management changes
Ok, this is now obsolete. I was too slow, I guess. :-) The following
patch (1) is no longer needed because Peter's new version has already
been committed, and (2) fails to pass a stacks.t test. But in case we
want to keep the neonate counters, here's an updated version of
Peter's original neonate flag patch. The message I would have sent:
===
On Sat, May 18, 2002 at 06:58:40PM -0400, Dan Sugalski wrote:
> At 11:05 PM +0200 5/18/02, Peter Gibbs wrote:
> >Unrelated subject: I see that Steve has modified string.c to get around the
> >problem with the temporary transcoded strings - I believe we need to
> >finalise a standard way of handling these situations soon. If anybody is
> >interested, I will resync my previous 'neonate' patch - it needs a bit of
> >work to fit with the latest changes to resources.c
>
> Did we get the "temporarily alive" bit patch in? If not, lets do that for
> now.
Ok. I snagged Peter's old neonate patch and updated it a bit. Note
that it does not add the op for clearing all occurrences of the flag;
instead, it explicitly unsets the flag in the handful of places it is
used. At the moment, this will never leak because even exceptions
leave through the same exit point. But eventually we'll need the op.
Any comments on/objections to the patch before I commit it? Would
BUFFER_temp_FLAG be more meaningful than BUFFER_neonate_FLAG? Any
other suggestions for a name?
patch follows
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.86
diff -u -r1.86 interpreter.c
--- interpreter.c 15 May 2002 05:01:15 - 1.86
+++ interpreter.c 20 May 2002 19:43:17 -
@@ -510,6 +510,9 @@
interpreter->memory_collected = 0;
interpreter->DOD_block_level = 1;
interpreter->GC_block_level = 1;
+interpreter->neonate_strings = 0;
+interpreter->neonate_buffers = 0;
+interpreter->neonate_PMCs = 0;
/* Set up the memory allocation system */
mem_setup_allocator(interpreter);
Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.55
diff -u -r1.55 resources.c
--- resources.c 20 May 2002 00:51:13 - 1.55
+++ resources.c 20 May 2002 19:43:22 -
@@ -502,6 +502,25 @@
}
}
+/* A buffer may be placed on the free list if all of:
+ * 1. It is vulnerable to collection (immune flag unset)
+ * 2. It is no longer alive (live flag unset)
+ * 3. It isn't already on the free list (on_free_list unset)
+ * 4. It is not marked neonate (temporary)
+ * 5. It is either not a constant, or it is a constant but it isn't being
+ * COW shared by another buffer.
+ */
+static INLINE int buffer_freeable(Buffer* b)
+{
+UINTVAL flags = b->flags;
+return !(flags & (BUFFER_immune_FLAG |
+ BUFFER_live_FLAG |
+ BUFFER_on_free_list_FLAG |
+ BUFFER_neonate_FLAG)) &&
+(!(flags & BUFFER_constant_FLAG) ||
+ (flags & BUFFER_COW_FLAG));
+}
+
/* Put any free buffers that aren't on the free list on the free list
* Free means: not 'live' and not immune */
static void
@@ -518,10 +537,7 @@
Buffer *b = cur_arena->start_Buffer;
for (i = 0; i < cur_arena->used; i++) {
/* If it's not live or on the free list, put it on the free list */-
if (!(b->flags & (BUFFER_immune_FLAG | BUFFER_live_FLAG |
- BUFFER_on_free_list_FLAG)) &&
-(!(b->flags & BUFFER_constant_FLAG) ||
- (b->flags & BUFFER_COW_FLAG))) {
+if (buffer_freeable(b)) {
interpreter->active_Buffers--;
b->flags = BUFFER_on_free_list_FLAG;
add_to_free_pool(interpreter, pool, b);
@@ -842,9 +858,7 @@
for (i = 0; i < cur_arena->used; i++) {
/* Is the string live, and can we move it? */
-if (!(s->flags & (BUFFER_on_free_list_FLAG |
- BUFFER_constant_FLAG | BUFFER_immobile_FLAG))
-&& s->bufstart) {
+if (s->bufstart && buffer_freeable((Buffer*) s)) {
memcpy(cur_spot, s->bufstart, s->buflen);
s->bufstart = cur_spot;
cur_size = s->buflen;
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
retrieving revision 1.77
diff -u -r1.77 string.c
--- string.c18 May 2002 02:38:13 - 1.77
+++ string.c20 May 2002 19:43:27 -
@@ -15,6 +15,25 @@
static const CHARTYPE *string_native_type;
static const CHARTYPE *string_unicode_type;
+/* Mark a string as temporary. Temporary strings are immune from garbage
+ * collection as long as the neonate flag is on. Call release_temp() to
+ * return a temporary to the chopping block. */
+static INLINE
Re: GC vtable method limitations?
> At 12:06 AM -0400 5/19/02, Mike Lambert wrote: > >Is there a plan to make a freed method for when pmc header gets put back > >onto the free list? (This would require we call this method on all pmc's > >before moving anything to the freelist, in case of dependancies between > >pmcs and buffers) > > Nope. I don't see a need--once the PMC's been destroyed, it belongs > to the system. Um. I see we have a destroy() vtable method, but it's only called when one calls the destroy() op, and the PMC has PMC_active_destroy_FLAG. I don't get this. What's the point of actively-destroying things? I thought since we had a GC, we don't need to worry about this kind of stuff. I'd argue that destroy() should get called when the PMC gets put back on to the free list (similar to destructors in C++). That was the behavior I was documenting when I discussed destruct below, at least. > Collect's dead, I think. I'm not seeing the point anymore, and since > we do collect runs through the buffers and not the PMCs, there's no > place to find what needs calling. Well, the hashtable could certainly use it. :) There is a hashtable pmc, which stores a bunch of pointers into some internal buffer data. Every time functions get called, it calls restore_invariants to fix them up. It might be better to do those fixups in the collect() method, so that they could update their internal data pointers. Or perhaps it should be rewritten to use indices. :) Mike Lambert
Re: [PATCH] Re: [netlabs #605] Attempt to modify a const STRING *yields compile error [APPLIED]
On 20 May 2002, David Lloyd wrote: > This patch removes the const-ness of those STRINGs that are modified. Applied, thanks.
[netlabs #605] Attempt to modify a const STRING * yields compile error
# New Ticket Created by David Lloyd
# Please include the string: [netlabs #605]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=605 >
I get:
cc -mt -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I./include -DHAS_JIT -DSUN4 -o string.o -c string.c
"string.c", line 274: left operand must be modifiable lvalue: op "|="
"string.c", line 281: left operand must be modifiable lvalue: op "&="
"string.c", line 432: left operand must be modifiable lvalue: op "|="
"string.c", line 521: left operand must be modifiable lvalue: op "&="
"string.c", line 579: left operand must be modifiable lvalue: op "|="
"string.c", line 582: left operand must be modifiable lvalue: op "|="
"string.c", line 599: left operand must be modifiable lvalue: op "&="
"string.c", line 600: left operand must be modifiable lvalue: op "&="
cc: acomp failed for string.c
gmake: *** [string.o] Error 2
for this bit of code:
STRING *
string_concat(struct Parrot_Interp *interpreter, const STRING *a,
const STRING *b, UINTVAL Uflags)
{
... some stuff ...
b->flags |= BUFFER_neonate_FLAG; /* <- modifies a const STRING * */
... more of the same ...
b->flags &= ~(UINTVAL)BUFFER_neonate_FLAG; /* ditto */
... etc ...
Either this needs to not be const or some other consideration needs to be
made.
- D
<[EMAIL PROTECTED]>
Re: [netlabs #602] [PATCH] Protect pack opcode from suicidal infants
On 20 May 2002, Peter Gibbs wrote: > # New Ticket Created by "Peter Gibbs" > # Please include the string: [netlabs #602] > # in the subject line of all future correspondence about this issue. > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=602 > > > > Attached patch to core.ops implements neonate protection for the 'pack' > opcode. The flag doesn't need to be cleared, since string_destroy handles > this. Applied, thanks, for some reason I asummed it was automagicaly setted :)
[netlabs #602] [PATCH] Protect pack opcode from suicidal infants
# New Ticket Created by "Peter Gibbs" # Please include the string: [netlabs #602] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=602 > Attached patch to core.ops implements neonate protection for the 'pack' opcode. The flag doesn't need to be cleared, since string_destroy handles this. -- Peter Gibbs EmKel Systems
Vtable Methods in Parrot
Has anyone given any thought to this problem yet? Will we be able to do this or do we need a special vtable whose entries automatically do a callback to Parrot? - D <[EMAIL PROTECTED]>
Re: GC vtable method limitations?
At 12:06 AM -0400 5/19/02, Mike Lambert wrote: >Is there a plan to make a freed method for when pmc header gets put back >onto the free list? (This would require we call this method on all pmc's >before moving anything to the freelist, in case of dependancies between >pmcs and buffers) Nope. I don't see a need--once the PMC's been destroyed, it belongs to the system. >We need to define what they are, and are not allowed to do. >As a general catch-all, we can say that no memory allocation or >deallocation may occur during any of these routines, although we should be >able to get more specific. I'll go update the docs. >collect: not sure what the goal of collect isto handle copying of your >memory data, in case you need to fixup pointers? What are the limitations >here? I'm going to say: no new headers or allocation of memory. (This >could cause stuff to be allocated in the old pool that doesn't get copied >over to the new one.) Collect's dead, I think. I'm not seeing the point anymore, and since we do collect runs through the buffers and not the PMCs, there's no place to find what needs calling. >destruct: Can do anything you want. We'll need to either increase our >DOD_block_level since it isn't re-entrant, but I don't think that's a big >problem. We can probably increment it before freeing all the >buffers, and decrement it when we're done. Works. I'll go update the docs. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot cvs
On Mon, 2002-05-20 at 17:47, Dan Sugalski wrote: > At 5:25 PM +0100 5/20/02, Alberto Manuel Brandão Simões wrote: > >Directory Parrot on root cvs parrot tree was deleted by hand, or why > >can't I update it? > > You're looking at the Parrot directory within parrot itself, right? > It was removed ages ago, and its contents moved into lib/. It was > conflicting with some case-insensitive systems. (Like OS X) OK. That's a good explanation. Thanks! Alberto > -- > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: Parrot cvs
At 5:25 PM +0100 5/20/02, Alberto Manuel Brandão Simões wrote: >Directory Parrot on root cvs parrot tree was deleted by hand, or why >can't I update it? You're looking at the Parrot directory within parrot itself, right? It was removed ages ago, and its contents moved into lib/. It was conflicting with some case-insensitive systems. (Like OS X) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [netlabs #601] [PATCH] Simplified version of temporary bufferimmunity patch [APPLIED]
Still, this problem is unsolved:
set I0,10
set S0,"#"
REDO: pack S1,1,S0
dec I0
print I0
print "\n"
if I0,REDO
end
Will core dump, because in :
inline op pack(inout STR, in INT, in STR) {
STRING *t,*s = $3;
UINTVAL len = (UINTVAL)$2;
char buf[3];
if (s->buflen < len) {
t = string_make(interpreter, buf, (UINTVAL)(len - s->buflen),
NULL, 0, NULL);
$1 = string_concat(interpreter, $1, s, 1);
} else {
t = string_make(interpreter, s->bufstart, (UINTVAL)len, NULL, 0,
NULL);
}
$1 = string_concat(interpreter, $1, t, 1);
string_destroy(t);
goto NEXT();
}
t gets collected, one way to solve this is to disable the GC inside the
op, but I don't know if that's the best way, thoughts?
Regards,
Daniel Grunblatt.
On Mon, 20 May 2002, Daniel Grunblatt wrote:
>
> On 20 May 2002, Peter Gibbs wrote:
>
> > # New Ticket Created by "Peter Gibbs"
> > # Please include the string: [netlabs #601]
> > # in the subject line of all future correspondence about this issue.
> > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=601 >
> >
> >
> > Attached is a simplified version of a previous patch to allow buffers to
> > avoid collection during their formative nanoseconds. This version covers the
> > basics:
> > A new flag - BUFFER_neonate_FLAG
> > This flag causes immunity from collection during DOD runs
> > The flag is set and cleared as required in string.c (note that there may be
> > more places that need flag setting, I just did a few obvious ones)
> >
> > This version makes no attempt to track the fact that there are newborns, or
> > to kill them if they try to keep this status for too long. It therefore
> > needs to be specifically used only when required. I am proposing this as an
> > interim solution until we decide on the best way of handling it permanently,
> > to overcome the current bugs without resorting to the performance-impacting
> > method of suppressing DOD runs.
> >
> > A few warnings in string.c have been removed in the process, along with some
> > duplicate #define's in string.h
> >
> > --
> > Peter Gibbs
> > EmKel Systems
> >
> >
>
> Applied, thanks.
>
>
Re: Parrot cvs
Try this: cvs -d ":pserver:[EMAIL PROTECTED]:/home/perlcvs" get parrot Daniel Grunblatt. On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote: > On Mon, 2002-05-20 at 17:58, Daniel Grunblatt wrote: > > On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote: > > > > > > > > Directory Parrot on root cvs parrot tree was deleted by hand, or why > > > can't I update it? > > > > It works fine for me. > > Anonymous CVS, of course > > cvs server: cannot open directoy /cvs/public/parrot/Parrot: No such file > or directory > > Hugs > Alberto > > -- > Alberto Manuel B. Simoes > Departamento de Informática - Universidade do Minho > http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net > >
Re: Parrot cvs
On Mon, 2002-05-20 at 17:58, Daniel Grunblatt wrote: > On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote: > > > > > Directory Parrot on root cvs parrot tree was deleted by hand, or why > > can't I update it? > > It works fine for me. Anonymous CVS, of course cvs server: cannot open directoy /cvs/public/parrot/Parrot: No such file or directory Hugs Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: Parrot cvs
On 20 May 2002, Alberto Manuel [ISO-8859-1] Brandão Simões wrote: > > Directory Parrot on root cvs parrot tree was deleted by hand, or why > can't I update it? It works fine for me.
Parrot cvs
Directory Parrot on root cvs parrot tree was deleted by hand, or why can't I update it? Thanks Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: [netlabs #601] [PATCH] Simplified version of temporary bufferimmunity patch [APPLIED]
On 20 May 2002, Peter Gibbs wrote: > # New Ticket Created by "Peter Gibbs" > # Please include the string: [netlabs #601] > # in the subject line of all future correspondence about this issue. > # http://bugs6.perl.org/rt2/Ticket/Display.html?id=601 > > > > Attached is a simplified version of a previous patch to allow buffers to > avoid collection during their formative nanoseconds. This version covers the > basics: > A new flag - BUFFER_neonate_FLAG > This flag causes immunity from collection during DOD runs > The flag is set and cleared as required in string.c (note that there may be > more places that need flag setting, I just did a few obvious ones) > > This version makes no attempt to track the fact that there are newborns, or > to kill them if they try to keep this status for too long. It therefore > needs to be specifically used only when required. I am proposing this as an > interim solution until we decide on the best way of handling it permanently, > to overcome the current bugs without resorting to the performance-impacting > method of suppressing DOD runs. > > A few warnings in string.c have been removed in the process, along with some > duplicate #define's in string.h > > -- > Peter Gibbs > EmKel Systems > > Applied, thanks.
[PATCH] old packfile patch
The disassembler isn't happy at the moment, this patch appears to fix
the problem it has with the bytecode header.
Index: lib/Parrot/PackFile.pm
===
RCS file: /home/perlcvs/parrot/lib/Parrot/PackFile.pm,v
retrieving revision 1.15
diff -p -r1.15 PackFile.pm
*** lib/Parrot/PackFile.pm 15 May 2002 04:33:29 - 1.15
--- lib/Parrot/PackFile.pm 20 May 2002 16:14:03 -
*** sub unpack
*** 187,206
$self->{MINOR} = shift_byte($string);
$self->{FLAGS} = shift_byte($string);
$self->{FLOATTYPE} = shift_byte($string);
!
! # Unused fields
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
!
! $string = substr($string, 8);
my $magic = shift_op($string);
--- 187,193
$self->{MINOR} = shift_byte($string);
$self->{FLAGS} = shift_byte($string);
$self->{FLOATTYPE} = shift_byte($string);
! $string = substr($string, 10);
my $magic = shift_op($string);
--
Jason
Index: lib/Parrot/PackFile.pm
===
RCS file: /home/perlcvs/parrot/lib/Parrot/PackFile.pm,v
retrieving revision 1.15
diff -p -r1.15 PackFile.pm
*** lib/Parrot/PackFile.pm 15 May 2002 04:33:29 - 1.15
--- lib/Parrot/PackFile.pm 20 May 2002 16:14:03 -
*** sub unpack
*** 187,206
$self->{MINOR} = shift_byte($string);
$self->{FLAGS} = shift_byte($string);
$self->{FLOATTYPE} = shift_byte($string);
!
! # Unused fields
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
! shift_byte($string);
!
! $string = substr($string, 8);
my $magic = shift_op($string);
--- 187,193
$self->{MINOR} = shift_byte($string);
$self->{FLAGS} = shift_byte($string);
$self->{FLOATTYPE} = shift_byte($string);
! $string = substr($string, 10);
my $magic = shift_op($string);
[netlabs #601] [PATCH] Simplified version of temporary buffer immunity patch
# New Ticket Created by "Peter Gibbs" # Please include the string: [netlabs #601] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=601 > Attached is a simplified version of a previous patch to allow buffers to avoid collection during their formative nanoseconds. This version covers the basics: A new flag - BUFFER_neonate_FLAG This flag causes immunity from collection during DOD runs The flag is set and cleared as required in string.c (note that there may be more places that need flag setting, I just did a few obvious ones) This version makes no attempt to track the fact that there are newborns, or to kill them if they try to keep this status for too long. It therefore needs to be specifically used only when required. I am proposing this as an interim solution until we decide on the best way of handling it permanently, to overcome the current bugs without resorting to the performance-impacting method of suppressing DOD runs. A few warnings in string.c have been removed in the process, along with some duplicate #define's in string.h -- Peter Gibbs EmKel Systems
Re: recursion in pasm (and timings)
Aldo Calpini wrote: > and now for timings: [...] em... forgot to include the platform details: OS: Windows 2000 Advanced Server + Cygwin 1.3.10 CPU: AMD K7 550MHz RAM: 256 MB cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
recursion in pasm (and timings)
hi there, the Examples page on www.parrotcode.org states this about subroutines: The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch and do not have to be preserved by the callee. this seems to be false for *recursive* subroutines. this is my PASM code fibo.pasm (it calculates the fibonacci number of 32): set I0, 32 bsr FIBO print I0 print "\n" end FIBO: lt I0, 2, FIBO_ONE set I1, I0 set I2, I1 dec I2, 2 set I0, I2 save I1 save I2 save I3 bsr FIBO restore I3 restore I2 restore I1 set I1, I0 inc I2 set I0, I2 save I1 save I2 save I3 bsr FIBO restore I3 restore I2 restore I1 add I0, I0, I1 branch FIBO_END FIBO_ONE: set I0, 1 FIBO_END: ret for this code to work correctly, I need to save and restore I1, I2, I3 on each recursive call. am I missing something or is just something that needs to be documented? and now for timings: I tested the new parrot (checked out some minutes ago) with JIT v2 enabled and these are the results: CPUMEM parrot fibo.pbc8.74736 parrot -j fibo.pbc 6.13772 just for reference, these are the times from other languages: CPUMEM Visual C++ (6.0) 0.13452 gcc (2.95.3) 0.20 1344 C# (7.00.9466) 0.24 3888 java (1.4.0-b92) 0.58 4972 python (2.1.1)14.72 2128 perl (5.6.1) 21.89 1416 ruby (1.6.5) 29.71 1912 note that comparison with parrot is not really fair because all the other programs accept the number (32 in our case) from the command line. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PATCH] Warnings cleanup
There are, at least native size issues, maybe not alignment issues; but thats why I left that fixme warning in packfile to remind us to go back and fix floats. At least the fetch routines do it per-byte so they don't care. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 Andy Dougherty te.edu> cc: Perl6 Internals <[EMAIL PROTECTED]> Subject: Re: [PATCH] Warnings cleanup 05/20/2002 10:55 AM On Sun, 19 May 2002, Mike Lambert wrote: > > This patch removes a bunch of warnings that have accumulated with MSVC > > recently. Thanks. I'm down to 934 warnings now :-). Index: packfile.c -self->number = PackFile_fetch_nv(pf, (unsigned char *)cursor); +self->number = PackFile_fetch_nv(pf, (opcode_t *)cursor); That cast shouldn't be necessary. cursor is already opcode_t *. (I also gather there are still alignment issues, since it isn't guaranteed that sizeof(FLOATVAL)/sizeof(opcode_t) is even an integer :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: [PATCH] Warnings cleanup
On Sun, 19 May 2002, Mike Lambert wrote: > > This patch removes a bunch of warnings that have accumulated with MSVC > > recently. Thanks. I'm down to 934 warnings now :-). Index: packfile.c -self->number = PackFile_fetch_nv(pf, (unsigned char *)cursor); +self->number = PackFile_fetch_nv(pf, (opcode_t *)cursor); That cast shouldn't be necessary. cursor is already opcode_t *. (I also gather there are still alignment issues, since it isn't guaranteed that sizeof(FLOATVAL)/sizeof(opcode_t) is even an integer :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[COMMIT] JIT v2
Folks, Yesterday I checked in the new JIT from Jason Gloudon. Now it does NOT depend on an external assembler and disassembler but instead uses some macros. All tests succesful. The size of the executable have been reduced by ~700K. It should work on most x86/sparc/alpha systems. Jason, Excellent work. Regards, Daniel Grunblatt.
Re: Profiling PMCs
At 6:09 PM +0100 5/19/02, Nicholas Clark wrote: >On Sat, May 18, 2002 at 07:33:53PM -0400, Dan Sugalski wrote: >> At 7:25 PM -0400 5/18/02, Melvin Smith wrote: >> >Yeh I know that word is yucky and from Java land, but in this case, >> >I think that >> >"system" PMCs should take liberties for optimization. >> >> *All* PMCs should take liberties for optimization. PMC vtable entries >> are the only things that should know the internal structures, and >> they're allowed--heck, encouraged--to take any liberties needed for >> speed. >> >> I don't much care if it breaks inheritance at the PMC level. Too bad. >> The speed's more important here. > >Is there any understandable and maintainable way that we can use the same >(base) code to generate two sets of core PMCs - one set that have all the >"cheating" optimisations, and another set (or set of code) that is >internally clean and can be inherited from? I'm not really sure we *should* be inheriting from base PMC classes at this level. Yeah, it's a nifty idea, but I don't know that it's appropriate here. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Non-vtable functionality on PMCs?
I've been trying to catch up with parrot again (darn it, babies take more time than I thought :) and I've come up with a question... how do you do "other" things to PMCs that aren't normal ops? In particular, I was wondering about shift/unshift, push/pop on the PerlArray PMC. Am I missing something obvious? Brian
Re: [COMMIT] inc/dec/add ops and new PMC methods
On Sun, May 19, 2002 at 06:01:56PM +0100, Nicholas Clark wrote: > > Seriously though - is it possible to automate testing how many ops don't > have tests? That way we could have a test that looked for untested ops, and > failed if any weren't tested. > I guess it couldn't easily be very sophisticated, in that it would really only > have to verify that all ops were mentioned somewhere in the body of a test, > but I think it could be quite useful. Or looking at it from the other end... automated coverage analysis of executed code would be a useful addition. Post processing the results could yield per-op, or at least per pmc, coverage value. I know coverage analysis isn't perfect but for ops in particular the devil is in the details and the edge cases are important. Tim.
Re: [netlabs #596] .XS build process needs to be more portable
Jeffrey Goff (via RT) wrote:
> I've just patched lib/Parrot/Makefile.PL to check for a Win32 platform,
> and if so, use .obj for the default object extension. However I did it
> simply by checking $^O for 'Win'. This is probably not as portable as it
> could be, but a quick look through ExtUtils::MakeMaker didn't reveal a
> variable that could be used for determining the proper extension.
I guess this is not portable, in fact. the Cygwin build under Win32 uses
.o extension as Unix does. but this seems to give a reasonable answer:
# perl -MConfig -e "print $Config{_o};"
.obj
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: GC design
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, there may be a way to avoid the overhead of the separate cleanup phase, if we enforce the rule that any objects created during a single opcode must be rooted at the end of the opcode or be disposable, and apply a variation of Melvin's generations: 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 function to be aware of what is happening) If an object is encountered during DOD that claims to be new, but was not created during the current opcode, dispute the claim. If the counter has exactly wrapped in the meantime, an object might survive longer than it should. Advantages Totally transparent outside of resources.c No additional passes required Objects will be reclaimed during the first DOD run after the creating opcode Disadvantages Additional field in PMC and Buffer headers Per-opcode counter required therefore fixed performance degradation Slightly more expensive logic to detect dead objects during DOD run Comments, anyone? I agree that something needs to be done quite urgently. As an example, Steve's current fix to string_concat (disable DOD) causes performance problems: Disabling DOD during string_concat: 5000 generations in 101.397038 seconds. 49.311105 generations/sec A total of 360896 bytes were allocated A total of 1501 DOD runs were made A total of 1474 collection runs were made Copying a total of 28677296 bytes There are 4770 active Buffer structs There are 14464 total Buffer structs With this change removed (life doesn't trigger the bug): 5000 generations in 97.344093 seconds. 51.364185 generations/sec A total of 57344 bytes were allocated A total of 101397 DOD runs were made A total of 5418 collection runs were made Copying a total of 7957080 bytes There are 102 active Buffer structs There are 512 total Buffer structs This highlights something that needs to be fixed anyway - blocked DOD runs are effectively cancelled, whereas they should just be postponed. -- Peter Gibbs EmKel Systems
