World: r3wp

Type "desktop" to start desktop.
WARNING: CALL function enabled in this version.
To see most recent beta changes, type: changes?
>> stats/frames
== [1536 1401 135 135 12522]
>>

with nothing else done

Type "desktop" to start desktop.
WARNING: CALL function enabled in this version.
To see most recent beta changes, type: changes?
>> recycle
>> stats/frames
== [1536 1121 415 415 11396]

I don't know exactly what means those values

Knowing some simple memory management techniques that assist recycle 
is useful, such as:

	my-big-binary-image: none
	unset 'my-big-object

 feel: my-feel	; instead of make .. where common code can be shared
	...

hmm.. under linux the internal version stops when I start it up after 
initial messages. It doesn't display a prompt...

>> help stats
USAGE:
    STATS /pools /types /series /frames /recycle /evals /clear

DESCRIPTION:
     System statistics.  Default is to return total memory used.
     STATS is a native value.

REFINEMENTS:

     /pools -- Returns: width units free-units units-per-alloc segments 
     mem-in-use
     /types -- Returns: Datatype count

     /series -- Returns: total blocks strings other avail free expansions
     /frames -- Returns: total used unused free values-total

     /recycle -- Returns: count series-total series-last frames-total 
     frames-last ballast
     /evals -- Returns: values functions blocks
     /clear -- Clears the evals counters

Ashley I know  this but that's not explain what means all the numbers 
in the recycle/frames result

That's one for Carl I think.

I think a "frame" is an internal interpreter structure or object.

but in fact the GC is problematic I would prefer a dealloc/realloc 
each time a ": " is found by the REBOL  code parse engine ;)

I think that would be very slow.

instead of having frames not related to a rebol word and  still allocated 
in memory until the GC decides to do he's job ;)

But I also admit my opinion is probably useless until I've studied 
and tested various garbage collection schemes.

Slow ?  slower than what letting the memory as this for sure  !!!!

that's right - slower.

but slower than making a recycle on every show function calls in 
Vid application like what was done in  rebgui  ?? I don't think so 
;)

you're trying to fight the system without coming up with a better 
one, that's all.

What is the true basic problem ?? I have in rebol memory chunks unrelated 
with world on the diccionnary of rebol  and this make the memory 
management just impossible because it dépends on too many things 
unrelated with coding ...

Anton well we are limited basicly be C capabilities If recylcle know 
what to frames to erase it"s normal to ask why those frames are not 
cleared before using new ones ;)

that's logic nothing more ;)

Anton well we are limited basicly by C capabilities If recylcle know 
what to frames to erase it"s normal to ask why those frames are not 
cleared before using new ones ;)

hundreds of line C code are spent into the recycle function but only 
one line could be used free () :)

well i'm too simpling the thing ...

Rebol is not the only one to use GC but it's the only one to give 
coders so little control upon it ;)

C is definitely not Rebol. But consider this:
	a: b: context [data: "love me"]
	a: none
Obviously the object should not be freed yet.

The question is, should a full recycle occur (checking for unattached 
values) ?

I think that would make setting words very slow and degrade performance 
terribly.

(After all, just about every second word in rebol code is a set-word.)

Anton it depends if a; and b; store each the cloned content ;)

No, the object is shared in this case.

>> recycle
>> stats
== 2936994
>> a: make object! [print "I love rebol but not GC"]
I love rebol but not GC
>> stats
== 2937746
>>

and

>> recycle
>> stats
== 2936994
>> a: b: make object! [print "I love rebol but not GC"]
I love rebol but not GC
>> stats
== 2937810
>>

as size are different into the 2 examples maybe the object is clonned 
...

No, they are not cloned. I can assure you of that.

you have it twice in memory but in fact no because if you make a: 
b: make object! [ test: 'test"]

And you should recycle and check stats multiple times before and 
after each test.

then a/test: "test200" print b/test

this shows the content to the shared object change ;)

sometimes the returned stats value is not stable.

Anton both code are witen into 2 separated consol

But we are polluting, I go to Performance group to continue this 
discussion...

if you make a:  make object you use less memory than a: b: make object! 
that's a fact ;)

in rebol there is an allocation table that will allow us to know 
if a data is share betwin several word  in the rebol diccionary

and obviously you will clear only single related data

where in the heck is that damn prompt...

henrik don't know I don't have tested it under linux ...

happens in core too now... no problems with an older rebol/view

Doing any startup scripts ? Check your user.r

no such file. created an empty user.r and now it won't start at all

you're trying to fight the system without coming up with a better 
one, that's all.

 OH OH Comon we are talking about a serrious issue and that's not 
 because I make  a criticise of the system that I have a better solution 
 ....