Wow! that's ingenious! And it's actually quite simple, which is almost
always the case with a good design! I'm going to
have to go away and take it all in. Thank you for the long winded
explanation. It wasn't long winded, it was concise given
the complexity of the subject matter. I've learned a great deal...
Rick McGuire wrote:
> Ok, time for one of my "long winded explanations".
>
> Yes, garbage collection is done using a mark-and-sweep algorithm, with
> a generational element to it (I'll cover that aspect last). The
> memory manager (AKA, memoryObject) holds a list of root set objects
> and also has a lists of subsystems (e.g., ActivityManager) that it
> will call as part of the memory management processing. The algorithm
> is pretty simple. The memory object calls the live() method on each
> of the root objects. The live() methods generally look something like
> this:
>
> void RexxString::live(size_t liveMark)
> /******************************************************************************/
> /* Function: Normal garbage collection live marking
> */
> /******************************************************************************/
> {
> memory_mark(this->NumberString);
> memory_mark(this->objectVariables);
> }
>
> The live() method is responsible for calling memory_mark() for every
> field that contains a reference to another object. memory_mark() is a
> macro that will check if a) the reference is non-null and b) the
> referenced object still requires marking. If it does require marking,
> the markObject() method of the memory manager is called with the
> reference. The object will be marked, and pushed on to the live stack
> for processing later.
>
> >From this point on, the marking algorithm is pretty simple. There's
> just a simple loop where an object is popped off of the live stack,
> and its live() method gets called. Eventually, the stack will be
> empty, and the sweep phase will begin. During the sweep phase, the
> memory heap is traversed, and any unmarked objects are combined and
> added back on to the free memory chains.
>
> There's one special category of memory, called the "oldspace". The
> oldspace is all of the objects that are contained in the file
> rexx.img. This is the Rexx image, and it basically contains the
> initial .environment tree. This image is designed to be quickly
> loaded and "reinflated" into working C++ objects whenever the
> interpreter intializes. Since none of these objects ever go away,
> they do not need to be marked during the GC phase. The oldspace
> objects have a special flag set in the object header and the
> memory_mark() macro uses that flag as part of the test for whether the
> object needs marking.
>
> The oldspace generation does add an additional complication to things.
> Since the oldspace objects do not get tracing during a garbage
> collection, then any newspace objects that have references stored in
> the oldspace will not get marked, which would be a "bad thing". To
> prevent this, there's a special table that keeps track of any
> cross-generation references. The table is managed via the OrefSet()
> macro, which needs to be used whenever a reference inside of one of
> these objects gets updated. The OrefSet() macro can detect this
> situation, and manage the references properly. It is extremely
> important that OrefSet() be used for setting reference-type variables,
> or some very bad (and hard to debug things can occur).
>
> Ok, now that I've said that, you might discover that there are some
> classes that don't use OrefSet at all. RexxActivation and
> RexxActivity would be two prominent examples. These classes are
> objects that are transient in nature and only exist while code is
> running. As a result, instances of these object would never get
> stored in the rexx.img file, so the cross-generational references can
> never occur. Since these classes tend to be on very heavily used code
> paths, they cheat a bit and don't use OrefSet because it would be
> extra overhead. In general, if you're not sure if OrefSet() is
> needed, then use it. If will never be an error to use it
> unnecessarily, but it will ALWAYS be an error to not use when it's
> required.
>
> Ok, that's the high level view. Feel free to ask questions about any
> areas you need additional information.
>
> Rick
>
>
>
>
>
> On Mon, Jul 21, 2008 at 8:13 AM, David Crayford <[EMAIL PROTECTED]> wrote:
>
>> Rick McGuire wrote:
>>
>>> On Mon, Jul 21, 2008 at 7:50 AM, David Crayford <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Thanks Rick, comments below...
>>>>
>>>> Rick McGuire wrote:
>>>>
>>>>
>>>>> Standard library objects need to be used with care because of storage
>>>>> management issues. Much of the internals of the interpreter is
>>>>> implemented using objects that are allocated from the Rexx-managed
>>>>> heap. These objects need to be constructed such that they are
>>>>> compatible with that memory management system, which the standard
>>>>> library objects are not.
>>>>>
>>>>>
>>>> STL objects have associated allocator policies. I've seen this used to
>>>> create STL
>>>> containers using UNIX shared memory. It's tricky, best left in the "too
>>>> hard" basket. I take it
>>>> it's ok to use STL algortihms?
>>>>
>>>>
>>> There are issues beyond just where the memory is allocated from. Any
>>> Rexx object
>>> allocated from the Rexx heap needs to be a subclass of RexxInternalObject
>>> and
>>> participate in the mark-and-sweep operations by implementing the
>>> live() and liveGeneral()
>>> methods. I think it's closer to the "not possible" basket than just
>>> merely being "too hard".
>>>
>>>
>>>
>> The lightbulb has just lit up and is shining brightly! I noticed the
>> live marking methods and presumed it was a
>> mark-and-sweep garbage collection scheme similar to Java. I would love
>> to understand the high level details
>> of how it works, scopes etc. In the C++ programming I do it's quite
>> common to use a smart pointer
>> like shared_ptr. I don't fully understand mark-and-sweep but I want to!
>>
>>> I'm not sure I understand what you mean by STL algorithms.
>>>
>>>
>>>
>> A simple use case is the min and max template functions.
>>
>>>>> As far as coding standards, a lot of the code is in transition from
>>>>> the coding standard I used in 1995 and the coding standard I prefer
>>>>> now. I don't like to get involved with the curly brace argument on
>>>>> placement and other stuff, but there are probably 3 "rules" I'd like
>>>>> to see followed:
>>>>>
>>>>> 1) Code indentation should be 4 spaces (the older code uses 2)
>>>>> 2) All if, for, while, etc. constructs should have curly braces
>>>>> (i.e., no "if (a = b) c = d;". The older code did not use that style,
>>>>> and I've been making a point of correcting this whenever I happen to
>>>>> be making changes in code that hasn't been converted yet. I will
>>>>> never object to anybody doing the same.
>>>>> 3) No had tabs. indentation should be done with spaces.
>>>>>
>>>>>
>>>>>
>>>> Great, perfectly suits my style. I use the SlickEdit editor which
>>>> introduced adaptive formatting in the
>>>> latest release. It adapts code assists to the convention it detects when
>>>> it opens the file. Brace style, indentation etc.
>>>> SlickEdit has very good support for classic REXX, including basic
>>>> context assist. Can I suggest that you add it your
>>>> list of editors that support REXX on your website. SlickEdit have
>>>> recently started to release instructions on
>>>> how to create user extensions to support proprietary languages. I'll put
>>>> this on my todo list for ooRexx.
>>>>
>>>>
>>>>> Other than that, I'm pretty flexible. Back in 1995, we tended to use
>>>>> line comments that had the /* and */ in specific columns. I prefer
>>>>> using the // form now. I don't see any need for changing the style
>>>>> that is there, nor should you make much of an attempt to try to keep
>>>>> the alignment.
>>>>>
>>>>>
>>>>>
>>>> On Mon, Jul 21, 2008 at 5:39 AM, David Crayford <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>>> I've been familiarising myself with the code and have noticed that
>>>>>> ooRexx does not use:
>>>>>>
>>>>>> * The standard C++ library, iostreams, STL etc.
>>>>>> * Exceptions
>>>>>> * Generic programming (templates)
>>>>>> * namespaces
>>>>>>
>>>>>> I assume that this is due to history (ooRexx older than ISO C++),
>>>>>> performance and portability reasons. Are there any coding standards
>>>>>> or rules that I should know about?
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>>>> prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>>>> world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> Oorexx-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>>> prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>>> world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Oorexx-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>>
>>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Oorexx-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
