World: r3wp

Not really. We can determine from testing the ways that it *doesn't* 
work.

We don't know the exact algorithm, but we know a lot about it, and 
that it's proprietary.

that's the kind of high level discussion that should conclude by 
a high level documentation about memory management and gc predictions 
... but probably better wasting the oportunity ... once again. I 
would not ask why?

GC stuff that we can figure out from experimentation and conversations:

- Mark and sweep
- Not generational or copying
- Probably zoned into block and binary/string zones.

Also, Carl has claimed that it is an algorithm that is unique to 
REBOL, though not gone into details.

I think adding a system like generational would be a big benefit 
to REBOL.  my guess is that Carl has a twist on this idea.

it's not the first time we have this discussion years ago we had 
this discussion about GC and memory management it's a cyclic concern 
and a cyclic discussion until we don't DC it :) ( Document & Collect 
it)

and because memory isn't released to the OS very often, I can make 
a fair guess that the GC doesn't compact on collect.

and clearly speaking about guru level stuff and not having a begining 
of a trail on such an issue makes me crazy just because noone wants 
to do this basic effort ...

but the GC can only be speculated to.  so there isn't alot of point 
in documenting assumptions.

anyway GC thing will tend to be less crucial with the default local 
vars in func no ?

unless Carl did a document about it, which would be very nice.  (hint 
hint ... RM-Asset guys?  ;-)

no since the memory allocated by any function still has to be managed 
by some sort of heap, since the data can and often does exist beyond 
the stack.

maxim hum you know you do a splendid documentation full of stupidities 
to make Carl go on verbose mode and correct it that's what it's called 
preach the false to obtain the true :)

that's some inverted spycology ...

spycology... hahaha... typo or not, its a good word.

The main reason that we haven't speculated on it is that it doesn't 
really matter what the real algorithm is, since it's internal and 
can't be swapped. All that matters is externally determinable traits, 
like whether data can move and when. Any moving collector requires 
a lot more effort to work with C libraries and extensions; that includes 
copying and generational collectors.

maxim or not :)

convenient dislexia :)

brianh in fact we had speculate alot of it with steeve and maxim 
around  spring 2009  when we were researching area-tc ... at that 
time i should have done a completly stupid high level documentation 
full of speculations maybe by now we would have better view on this 
particular topic

the extensions API actually marshals all of that so the internals 
of the GC don't really affect the host kit that much.  


A part from the raw image! data, we don't really have any reason 
to believe that any pointer we share with the core is persistent.


In any case I don't rely on it, because AFAIK Carl has insinuated 
that we never really have access to the internals and pointers we 
get are actually interfaces, not interal references (for security 
reasons).

the issue is that the GC does affect my code a lot in big apps and 
I'd like to know exactly when and how it works so I can better guess 
when its about to jerk my code in an animation or while I'm scrolling 
stuff.

exactly when and how it works
 - there are at least two reasons why this is what you can't get:


1) *when* the GC works is "unpredictable" from the programmer's POV 
(depending on other code, etc.)

2) It is (or may be) subject to adjustments or changes, without the 
programmer being able to detect such changes, so why should he know?

3) programming for a specific GC variant should be seen as a typical 
bad practice - why should you want to make code that is supposed 
to work only in specific circumstances? Not to mention, that you 
actually cannot do that anyway, since the GC should be programmed 
to hide any implementation details

As to why I know the GC does not count references: I know it, since 
it is documented widely, that reference counting cannot be used for 
garbage collection in general environments.

Refcounting w/ cycle detection or or a hybrid refcounting + tracing 
approach certainly can.

But in various bits and pieces of REBOL documentation it's hinted 
at that the REBOL GC being a tracing mark-sweep variant. And I seem 
to recall that Carl affirmed this at least once, but I don't have 
any link to the source handy.

I think it is safe to consider REBOL GC to be mark&sweep. But am 
totally at odds, how that can help Max write any of his code.

this is just helpfull for debugging.   its very usefull to track 
down memory leaks, which are pretty easy to create in GC systems 
since we don't manage any part of it.

also If it has several heaps, or tricks like generations, or whatever 
, we can optimise the code so that we make it work in the "best case" 
of the GC instead of the worst case.


right now all I know is that the GC is very disruptive in very large 
apps (in R2) because you can actually see the application jam for 
a noticeable amount of time when there is animation or interactive 
things being done.

Alas, that kind of problem is exactly why you don't want to rely 
on the implementation model of the GC. One thing we know about the 
GC is that it is the stop the world type. If we need to solve the 
problem you mention, we would have to completely replace the internal 
memory model with a different one and use a GC with a completely 
different algorithm (generational, incremental, parallel, whatever). 
That means that all of your code optimizations would no longer work. 
If you don't try to optimize your code to the GC, it makes it possible 
to optimize the GC itself.

BrianH, if I deliver an application to a client and he says to my 
face... why does it jerk every 2 seconds?


I really don't care about if the GC might change.  right now I can't 
do anything to help it.


if it changes, I will adapt my code to it again.   This is platform 
tuning and it is inherently "close to the metal", but in the real 
life, such things are usefull to do... 

just look at the 1 second boot linux machine in that other group.

something like this document (which has a Best Practices at the end) 
would be really nice.


http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry

obviously, since the GC is a "stop the world" system, I can't fix 
everything, but I might be able to help it along a little bit.

You can time when you call it...

I'm hoping that we might get a better collector when we work R3 over 
for concurrency.

yes, with proficient concurrency, its much easier to make non-blocking 
GC.

easier being a relative term  ;-)

It might be the other way around. It's harder to stop a multitasking 
world than it is to stop a single-tasking one...

recycle/ballast avoid the "stop the world" issue if well balaned

*balanced

How about a minor addition to/restructuring of the comparison functions:
- equal?
- equiv?: equal + binding

- strict-equal?: equal + type + case + alias + decimal  (but _no_ 
binding)
- srict-equiv?: strict-equal + binding
- same?: as currently


(See http://www.rebol.net/wiki/Comparisons#EQUAL.3Ffor the status 
quo.)

Alias?

See the referenced document.

strict-* makes alias distinctions.

Oh, right. All words are aliased. That's how case insensitivity is 
implemented in R3. So case = alias for words.

maybe alias implies case, but case does not imply alias.

What we seem to be missing at the moment is a comparison function 
with ignores binding but is otherwise "strict" in the sense of type/case/alias/decimal 
precision.

If we had such a function, the discussion around #1830 and related 
issues (such as a more useful map! type) would be much easier.

The proposal above now is to have equal/strict-equal not respect 
binding, and have equiv/strict-equiv be their binding-respecting 
counterparts.