Re: Bugfix release?
On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. -- Everything I wanted to get in to a 0.0.5 release is there now.
Re: Bugfix release?
Dan Sugalski [EMAIL PROTECTED] wrote
With the recent stack and GC patches, are we pretty much solid now?
If so, a 0.0.5 bugfix release may well be in order.
The one outstanding issue that I know of is the mem_realloc problem in
add_pmc_to_free and add_header_to_free. Since the problem is actually
endemic to mem_realloc, the best solution seems to be a replacement for
mem_realloc that takes a Buffer*, so that an intervening GC run still leaves
it knowing where the source is.
In line with a previous suggestion, I propose that such a routine be called
Parrot_reallocate.
A patch to create such a function and use it within add_pmc_to_free and
add_header_to_free follows; since all uses of mem_realloc are potentially at
risk, it might be a good idea to change any such places also.
--
Peter Gibbs
EmKel Systems
Index: include/parrot/resources.h
===
RCS file: /home/perlcvs/parrot/include/parrot/resources.h,v
retrieving revision 1.25
diff -u -r1.25 resources.h
--- include/parrot/resources.h 18 Mar 2002 22:09:10 - 1.25
+++ include/parrot/resources.h 30 Mar 2002 14:58:26 -
@@ -31,6 +31,7 @@
void *Parrot_allocate(struct Parrot_Interp *, size_t size);
void *Parrot_alloc_new_block(struct Parrot_Interp *, size_t, UINTVAL);
+void Parrot_reallocate(struct Parrot_Interp *, Buffer *, size_t);
void Parrot_new_pmc_header_arena(struct Parrot_Interp *interpreter);
Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.37
diff -u -r1.37 resources.c
--- resources.c 30 Mar 2002 05:57:32 - 1.37
+++ resources.c 30 Mar 2002 14:57:38 -
@@ -18,22 +18,18 @@
static void add_header_to_free(struct Parrot_Interp *interpreter,
struct free_pool *pool, void *to_add);
-/* Add a string header to the free string header pool */
+/* Add a PMC header to the free pool */
static void add_pmc_to_free(struct Parrot_Interp *interpreter,
struct free_pool *pool, void
*to_add) {
PMC **temp_ptr;
/* First, check and see if there's enough space in the free pool. If
- we're within the size of a STRING pointer, we make it bigger */
+ we're within the size of a pointer, we make it bigger */
if (pool-entries_in_pool * sizeof(PMC *) =
pool-pool_buffer.buflen - sizeof(PMC *)) {
/* If not, make the free pool bigger. We enlarge it by 20% */
-pool-pool_buffer.bufstart = mem_realloc(interpreter,
- pool-pool_buffer.bufstart,
- pool-pool_buffer.buflen,
-
(UINTVAL)(pool-pool_buffer.buflen * 1.2));
-pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
-
+size_t new_size = pool-pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, pool-pool_buffer, new_size);
}
/* Okay, so there's space. Add the header on */
@@ -273,12 +269,8 @@
if (pool-entries_in_pool * sizeof(STRING *) =
pool-pool_buffer.buflen - sizeof(STRING *)) {
/* If not, make the free pool bigger. We enlarge it by 20% */
-pool-pool_buffer.bufstart = mem_realloc(interpreter,
- pool-pool_buffer.bufstart,
- pool-pool_buffer.buflen,
-
(UINTVAL)(pool-pool_buffer.buflen * 1.2));
-pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
-
+size_t new_size = pool-pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, pool-pool_buffer, new_size);
}
/* Okay, so there's space. Add the header on */
@@ -879,6 +871,25 @@
}
}
return (void *)return_val;
+}
+
+/* Change the size of a buffer/string created by Parrot_allocate
+ Input parameter is a pointer to the Buffer or String structure
+ bufstart is updated to point to the new memory
+ buflen is updated to the new length
+ min(buflen,new_size) bytes are copied from old location to new location
+*/
+void
+Parrot_reallocate(struct Parrot_Interp *interpreter, Buffer *buffer, size_t
new_size) {
+size_t copysize = (buffer-buflen new_size ? new_size :
buffer-buflen);
+void *new_ptr = Parrot_allocate(interpreter, new_size);
+if (!new_ptr) {
+internal_exception(ALLOCATION_ERROR,
+ Out of memory during buffer reallocation);
+}
+memcpy(new_ptr, buffer-bufstart, copysize);
+buffer-bufstart = new_ptr;
+buffer-buflen = new_size;
}
/* Tag a buffer header as alive. Used by the GC system when tracing
Re: Bugfix release?
At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. My crashme program crashes no more, we are 10x more stable than a week ago. I think Peter's patch or a variation is in order, and I'm also working on a new crashme :) Bring on 0.0.5 -Melvin
Re: Bugfix release?
On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. -- I'm still getting a test failure on stacks.t, in test #7. Until that's fixed, I'm holding off committing Michel Lambert's CGoto.pm patch. I'd also like to get my patch for core key support committed for 0.0.5, but I don't want to commit it either when tests are failing. It is necessary for accessing command-line arguments and for the group stuff to work in rx.ops. (And it makes PerlArrays usable, which is very helpful for other development.) -- WM ISO JOB. http://foxglove.dnsalias.org/~sfink/job.html C, perl, networking, performance optimization, Java, XML.
Re: Bugfix release?
On Sat, Mar 30, 2002 at 10:47:11AM -0800, Steve Fink wrote: On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. -- I'm still getting a test failure on stacks.t, in test #7. Until that's fixed, I'm holding off committing Michel Lambert's CGoto.pm patch. Ok, never mind. For whatever reason, I'm not getting the test failure anymore. I didn't think it touched any common code, but perhaps the patch fixed it? I just committed the patch.
Re: Bugfix release?
On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote: At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. My crashme program crashes no more, we are 10x more stable than a week ago. I think Peter's patch or a variation is in order, and I'm also working on a new crashme :) Bring on 0.0.5 Peter's made it foolproof, so Melvin is about to build a better fool? :-) Long may this arms race continue. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Bugfix release?
At 6:45 PM + 3/30/02, Nicholas Clark wrote: On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote: At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. My crashme program crashes no more, we are 10x more stable than a week ago. I think Peter's patch or a variation is in order, and I'm also working on a new crashme :) Bring on 0.0.5 Peter's made it foolproof, so Melvin is about to build a better fool? :-) Long may this arms race continue. We can always use a higher-class of fool, that's for sure. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bugfix release?
Dan Sugalski [EMAIL PROTECTED] wrote With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. The one outstanding issue that I know of is the mem_realloc problem in add_pmc_to_free and add_header_to_free. Since the problem is actually endemic to mem_realloc, the best solution seems to be a replacement for mem_realloc that takes a Buffer*, so that an intervening GC run still leaves it knowing where the source is. In line with a previous suggestion, I propose that such a routine be called Parrot_reallocate. A patch to create such a function and use it within add_pmc_to_free and add_header_to_free follows; since all uses of mem_realloc are potentially at risk, it might be a good idea to change any such places also. This patch looks good to me. It fixes the test case that was posted earlier, and it's much better from a design standpoint than the previous patch, which was withheld. I'm also working on code that builds off this patch, so I'd appreciate if it was applied. Thanks, Mike Lambert
Re: Bugfix release?
At 04:59 PM 3/30/2002 +0200, Peter Gibbs wrote:
Dan Sugalski [EMAIL PROTECTED] wrote
With the recent stack and GC patches, are we pretty much solid now?
If so, a 0.0.5 bugfix release may well be in order.
The one outstanding issue that I know of is the mem_realloc problem in
add_pmc_to_free and add_header_to_free. Since the problem is actually
endemic to mem_realloc, the best solution seems to be a replacement for
mem_realloc that takes a Buffer*, so that an intervening GC run still leaves
it knowing where the source is.
In line with a previous suggestion, I propose that such a routine be called
Parrot_reallocate.
A patch to create such a function and use it within add_pmc_to_free and
add_header_to_free follows; since all uses of mem_realloc are potentially at
risk, it might be a good idea to change any such places also.
I like this patch much better. I'll commit this if there are no other comments
from the rest of the group.
-Melvin
--
Peter Gibbs
EmKel Systems
Index: include/parrot/resources.h
===
RCS file: /home/perlcvs/parrot/include/parrot/resources.h,v
retrieving revision 1.25
diff -u -r1.25 resources.h
--- include/parrot/resources.h 18 Mar 2002 22:09:10 - 1.25
+++ include/parrot/resources.h 30 Mar 2002 14:58:26 -
@@ -31,6 +31,7 @@
void *Parrot_allocate(struct Parrot_Interp *, size_t size);
void *Parrot_alloc_new_block(struct Parrot_Interp *, size_t, UINTVAL);
+void Parrot_reallocate(struct Parrot_Interp *, Buffer *, size_t);
void Parrot_new_pmc_header_arena(struct Parrot_Interp *interpreter);
Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.37
diff -u -r1.37 resources.c
--- resources.c 30 Mar 2002 05:57:32 - 1.37
+++ resources.c 30 Mar 2002 14:57:38 -
@@ -18,22 +18,18 @@
static void add_header_to_free(struct Parrot_Interp *interpreter,
struct free_pool *pool, void *to_add);
-/* Add a string header to the free string header pool */
+/* Add a PMC header to the free pool */
static void add_pmc_to_free(struct Parrot_Interp *interpreter,
struct free_pool *pool, void
*to_add) {
PMC **temp_ptr;
/* First, check and see if there's enough space in the free pool. If
- we're within the size of a STRING pointer, we make it bigger */
+ we're within the size of a pointer, we make it bigger */
if (pool-entries_in_pool * sizeof(PMC *) =
pool-pool_buffer.buflen - sizeof(PMC *)) {
/* If not, make the free pool bigger. We enlarge it by 20% */
-pool-pool_buffer.bufstart = mem_realloc(interpreter,
- pool-pool_buffer.bufstart,
- pool-pool_buffer.buflen,
-
(UINTVAL)(pool-pool_buffer.buflen * 1.2));
-pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
-
+size_t new_size = pool-pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, pool-pool_buffer, new_size);
}
/* Okay, so there's space. Add the header on */
@@ -273,12 +269,8 @@
if (pool-entries_in_pool * sizeof(STRING *) =
pool-pool_buffer.buflen - sizeof(STRING *)) {
/* If not, make the free pool bigger. We enlarge it by 20% */
-pool-pool_buffer.bufstart = mem_realloc(interpreter,
- pool-pool_buffer.bufstart,
- pool-pool_buffer.buflen,
-
(UINTVAL)(pool-pool_buffer.buflen * 1.2));
-pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
-
+size_t new_size = pool-pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, pool-pool_buffer, new_size);
}
/* Okay, so there's space. Add the header on */
@@ -879,6 +871,25 @@
}
}
return (void *)return_val;
+}
+
+/* Change the size of a buffer/string created by Parrot_allocate
+ Input parameter is a pointer to the Buffer or String structure
+ bufstart is updated to point to the new memory
+ buflen is updated to the new length
+ min(buflen,new_size) bytes are copied from old location to new location
+*/
+void
+Parrot_reallocate(struct Parrot_Interp *interpreter, Buffer *buffer, size_t
new_size) {
+size_t copysize = (buffer-buflen new_size ? new_size :
buffer-buflen);
+void *new_ptr = Parrot_allocate(interpreter, new_size);
+if (!new_ptr) {
+internal_exception(ALLOCATION_ERROR,
+ Out of memory during buffer reallocation);
+}
+memcpy(new_ptr, buffer-bufstart, copysize);
+buffer-bufstart = new_ptr;
+buffer-buflen = new_size;
}
/* Tag a buffer header as alive. Used by the GC system when tracing
Re: Bugfix release?
At 06:45 PM 3/30/2002 +, Nicholas Clark wrote: On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote: At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote: With the recent stack and GC patches, are we pretty much solid now? If so, a 0.0.5 bugfix release may well be in order. My crashme program crashes no more, we are 10x more stable than a week ago. I think Peter's patch or a variation is in order, and I'm also working on a new crashme :) Bring on 0.0.5 Peter's made it foolproof, so Melvin is about to build a better fool? :-) Long may this arms race continue. Who better to build a better fool but a fool? *grin* -Melvin
