Hello all! I'm trying to figure out how the NativeCall interface
releases memory for objects with native representation, and I could
use some help.
For what I can see:
* CPointer never frees anything
https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/CPointer.c#L148
* CStr always fre
Hello all! I'm trying to figure out how the NativeCall interface
releases memory for objects with native representation, and I could
use some help.
For what I can see:
* CPointer never frees anything
https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/CPointer.c#L148
* CStr always fre
Justin has left a new comment on your post "Memory Management in PIRC":
APR is the Apache Runtime library. It's centered around the idea that
all allocations are done for some specific request/task and that most
(or even all) of that memory will be needed for the duration of th
Justin has left a new comment on your post "Memory Management in PIRC":
That's one way to do it. Why not the APR way of things? Creating memory
pools in which memory can only be allocated (not freed) and after each
step is finished you simpy reclaim the entire pool (no fragmentat
kjs has left a new comment on your post "Memory Management in PIRC":
Justin, thanks for sharing your thoughts. I'm not sure what "APR" way
of things is.. Creating memory pools and reclaiming the pool after each
step: all allocated memory is needed till the end of the c
On Oct-22, Steve Fink wrote:
> On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote:
> > The last one looks like a fundamental problem in MultiArray.
> > The line
> > b->cell_buffer = new_buffer_header(interpreter);
> > in function new_marray is creating a new buffer header, overwriting
> >
On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote:
> The last one looks like a fundamental problem in MultiArray.
> The line
> b->cell_buffer = new_buffer_header(interpreter);
> in function new_marray is creating a new buffer header, overwriting
> the new_bufferlike_header created earlie
Mike Lambert wrote:
> http:[EMAIL PROTECTED]/msg11553.html
Thanks for this. I must have missed some parts of this discussion on the
list. Aligning the header pools could be an interesting approach, since
now a considerable amount of time is spent to determine if a pointer on
the sysem stack
> >>First and foremost, is there any compelling reason, to have totally
> >>different structures for PMCs and Buffers?
> >>- Both have a ->data aka ->bufstart
> >>- Both have ->flags, that have vastly the same meaning.
> >>
> >
> > As jason said in another message, Dan has changed his mind from
>
Mike Lambert wrote:
[ Unifying Buffer and PMC ]
> As jason said in another message, Dan has changed his mind from
> yesteryear, and decided that buffers and pmcs should be the same
> structure.
Roadmap
---
1) Hide Buffer and PMC internals, namely
- buflen
- bufstart
- flags
Mike Lambert wrote:
>>First and foremost, is there any compelling reason, to have totally
>>different structures for PMCs and Buffers?
>>- Both have a ->data aka ->bufstart
>>- Both have ->flags, that have vastly the same meaning.
>>
>
> As jason said in another message, Dan has changed his mind
> First and foremost, is there any compelling reason, to have totally
> different structures for PMCs and Buffers?
> - Both have a ->data aka ->bufstart
> - Both have ->flags, that have vastly the same meaning.
As jason said in another message, Dan has changed his mind from
yesteryear, and decide
On Fri, Sep 27, 2002 at 09:28:41AM +0200, Leopold Toetsch wrote:
> First and foremost, is there any compelling reason, to have totally
> different structures for PMCs and Buffers?
The reasons stopped being compelling about a month or two ago, when it was
decided to unify the two. No one has had
I have some questions and suggestions regarding PMCs, Buffers and memory
management/internal data structures.
First and foremost, is there any compelling reason, to have totally
different structures for PMCs and Buffers?
- Both have a ->data aka ->bufstart
- Both have ->flags, that ha
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
On Sat, May 18, 2002 at 06:58:40PM -0400, Dan Sugalski wrote [to P. Gibbs]:
> Did we get you commit privs? If so, commit it. If not, get me your
> perl.org login and I'll get it taken care of.
In the meantime, I committed that patch.
y the extra space in string headers for a start
of string in addition to a start of buffer, and since the only things
that care about it live in string.c, that's fine. So go ahead--I
expect it may make COW a bit easier.
>Once the latest memory management patch is in, I will resync and su
compact_string_pool very cumbersome, and the performance was several percent
slower than my current implementation.
Once the latest memory management patch is in, I will resync and submit the
COW code as a separate patch, and we'll see what everybody thinks about it.
I have just done a benchmark
At 10:29 AM -0700 5/18/02, Steve Fink wrote:
>On Sat, May 18, 2002 at 12:18:14PM -0400, Dan Sugalski wrote:
>> At 9:53 PM +0200 5/15/02, Peter Gibbs wrote:
>> >The attached patch is the next set of proposed changes to the memory
>> >management routines, with the
On Sat, May 18, 2002 at 12:18:14PM -0400, Dan Sugalski wrote:
> At 9:53 PM +0200 5/15/02, Peter Gibbs wrote:
> >The attached patch is the next set of proposed changes to the memory
> >management routines, with the copy-on-write logic removed.
>
> Peter, did these go in?
I
At 9:53 PM +0200 5/15/02, Peter Gibbs wrote:
>The attached patch is the next set of proposed changes to the memory
>management routines, with the copy-on-write logic removed.
Peter, did these go in?
--
Dan
-
icated code for the free_pool_buffers. But your patch is a
*much* better way of doing that part.
Mostly, I didn't want to make any major changes without the buy-in of
the head memory management guys (which primarily means you at the
moment.) I've finally managed to get a grip on the differen
The attached patch is the next set of proposed changes to the memory
management routines, with the copy-on-write logic removed.
Performance numbers on my 166-MHz Pentium (linux 2.2.18) for 5000-generation
life.pasm are:
Current CVS - 50.41 generations/second
With this patch - 57.40
With COW
Steve Fink wrote:
>
> On Sun, May 05, 2002 at 08:43:17PM -0700, Steve Fink wrote:
> > On Sat, May 04, 2002 at 11:14:06PM -0400, Jeff wrote:
> > > Daniel Grunblatt wrote:
> > > >
> > > > On Sat, 4 May 2002, Steve Fink wrote:
> > > >
> > > > > Applied, with one change: the alignments of the three p
On Sun, May 05, 2002 at 08:43:17PM -0700, Steve Fink wrote:
> On Sat, May 04, 2002 at 11:14:06PM -0400, Jeff wrote:
> > Daniel Grunblatt wrote:
> > >
> > > On Sat, 4 May 2002, Steve Fink wrote:
> > >
> > > > Applied, with one change: the alignments of the three pools are now
> > > > #defined.
>
On Sat, May 04, 2002 at 11:14:06PM -0400, Jeff wrote:
> Daniel Grunblatt wrote:
> >
> > On Sat, 4 May 2002, Steve Fink wrote:
> >
> > > Applied, with one change: the alignments of the three pools are now
> > > #defined.
> > >
> >
> > I believe your commit was incomplete.
>
> I'd have to agree.
Peter Gibbs wrote:
>
> Mike Lambert wrote:
> > Wow. Tinderbox gave us fall and spring in a few hour period. Nice. Here's
> > a patch to help make us make it to summer again.
>
> Steve actually pointed out that this style of code was not safe, but I still
> managed to miss that one.
>
> > -
Mike Lambert wrote:
> Wow. Tinderbox gave us fall and spring in a few hour period. Nice. Here's
> a patch to help make us make it to summer again.
Steve actually pointed out that this style of code was not safe, but I still
managed to miss that one.
> -(char *)cur_buffer += pool->unit_si
> Commit completed. One thing I find handy when patching is to run a CVS
> update, make distclean, and rebuild/retest on my local platform. This
> helps catch misapplied and incomplete patches.
Wow. Tinderbox gave us fall and spring in a few hour period. Nice. Here's
a patch to help make us make
Jeff wrote:
>
> Daniel Grunblatt wrote:
> >
> > On Sat, 4 May 2002, Steve Fink wrote:
> >
> > > Applied, with one change: the alignments of the three pools are now
> > > #defined.
> > >
> >
> > I believe your commit was incomplete.
Commit completed. One thing I find handy when patching is to run
Daniel Grunblatt wrote:
>
> On Sat, 4 May 2002, Steve Fink wrote:
>
> > Applied, with one change: the alignments of the three pools are now
> > #defined.
> >
>
> I believe your commit was incomplete.
I'd have to agree. Some of the code appears to use 'last_PMC_Arena',
which isn't defined yet i
On Sat, 4 May 2002, Steve Fink wrote:
> Applied, with one change: the alignments of the three pools are now
> #defined.
>
I believe your commit was incomplete.
Applied, with one change: the alignments of the three pools are now
#defined.
Steve Fink wrote:
>
> Why use 2-byte alignment on constant strings? Wouldn't it speed up
> memory copies to make them always be 4-byte aligned? (Or
> machine-register-size aligned?)
Changed to 4-byte alignment for now. If there is a specific sizeof(X) you
would prefer, just change it.
> 1. Can y
On Fri, May 03, 2002 at 04:57:37PM +0200, Peter Gibbs wrote:
> Attached is the second set of patches for the tracked resource memory
> management system.
>
> Features:
> Separate memory pools for buffers, normal strings, constant strings; the
> latter is never compacted
>
Attached is the second set of patches for the tracked resource memory
management system.
Features:
Separate memory pools for buffers, normal strings, constant strings; the
latter is never compacted
Each pool has its own alignment; these are currently set to 16, 4 and 2
respectively; suggestions
On Sat, Apr 27, 2002 at 05:06:08PM -0400, Mike Lambert wrote:
> > For (1), maybe we should add an opcode: get_number_of_live_objects?
> > Then you could write a test case that records the number of live
> > objects, does stuff, forces a sweep and collect, and checks that the
> > saved number + #ex
> For (1), maybe we should add an opcode: get_number_of_live_objects?
> Then you could write a test case that records the number of live
> objects, does stuff, forces a sweep and collect, and checks that the
> saved number + #expected live objects is equal to the currently live
> number?
I agree
On Sat, Apr 27, 2002 at 12:30:56PM -0700, Steve Fink wrote:
> For (1), maybe we should add an opcode: get_number_of_live_objects?
> Then you could write a test case that records the number of live
> objects, does stuff, forces a sweep and collect, and checks that the
> saved number + #expected liv
I'll paste a diff -ub below to show the changes without the
reindentation noise.
I am about to commit a patch that:
- Fixes a bit test bug, changing to
bits == (bitA | bitB)
from
bits == (bitA & bitB))
- Count of elements in an array of PMCs was wrong. It was looping
over PMC*
Okay folks, a quick heads up.
*Any* function in the parrot core that allocates a parrot-managed structure
(such as a string or PMC) *must* have a valid interpreter structure hanging
around. I'm in the middle of rejigging everything so we can start
allocating PMCs & string structures, and prope
41 matches
Mail list logo
