Changes between Version 4 and Version 5 of MakeEveryPMCAnObject

Show
Ignore:
Timestamp:
02/01/11 06:18:45 (3 years ago)
Author:
cotto
Comment:

most of these changes are rejected, but primarly because they'll be accomplished through M0 and 6model, not because they're bad ideas

Legend:

Unmodified
Added
Removed
Modified
  • MakeEveryPMCAnObject

    v4 v5  
    22 
    33 
    4 == Comments == 
    5  
    6 The status as it is on 28 okt 2009. See branch tt_1020 for more details. [[BR]] 
    7 (broken at the moment will be fixed tomorrow I hope,small svn problem) [[BR]] 
    8 [[BR]] 
    9 This will give some extra detail on the plan and will give a view on the current status. [[BR]] 
    10 Any comments are welcome. [[BR]] 
    11 [[BR]] 
    12  
    13  
    144== All pmc become an object and attribute indexing system == 
     5 
     6Note: Lorito will have a unification between objects and PMCs.  The rest doesn't really apply to M0, though using 64-bit floats may be worth considering. 
    157 
    168The functionality in object.pmc will move to default.pmc. With this action everything will 
     
    5446[[BR]] 
    5547 
    56 == Core pmcs with fully defined class definition == 
     48== ~~Core pmcs with fully defined class definition~~ == 
     49 
     50Note: rejected.  We're going with 6model (or something similar) for all PMCs. 
    5751 
    5852All core pmcs get a full describing pmcclass object as a  
     
    9488[[BR]] 
    9589 
    96 == Replace vtable ref by ref to class == 
     90== ~~Replace vtable ref by ref to class~~ == 
     91 
     92Note: rejected.  6model will mean deep changes to PMCs and objects, so this won't apply. 
    9793 
    9894Since all pmc will become an object, there will be a field pointing to the pmcclass object. 
     
    110106[[BR]] 
    111107 
    112 == Class description in separate gc pool, no deletion during runtime == 
    113  
    114 Because a pmcclass object, which describes a class has got a more central role and the information is used 
    115 for the removal of an object, are they stored in a seperate gc small object arena. Class object will 
    116 run the mark function and mark other object, but will for now will not get automatically removed.  
    117 This means when a class is defined it will stay in the memory until shutdown.  
    118 These can ofcourse be fixed in the future, but this "problem" has also been 
    119 for a while in the jvm, so I think it will not be a big problem. Once the gc system get finalized, the pmcclass object 
    120 which describes the class itself will get removed as the last one. See code src/gc/*.c. [[BR]] 
    121 [[BR]] 
    122  
    123 == Get/set attribute == 
     108== ~~Class description in separate gc pool, no deletion during runtime~~ == 
     109 
     110Note: This idea is rejected.  A generational gc will dtrt here. 
     111 
     112== ~~Get/set attribute~~ == 
     113 
     114Note: rejected, more or less.  6model has a similar way of handling attributes and avoids the pmcproxy. 
    124115 
    125116The "get_attr_str","get_attr_keyed","set_attr_str","set_attr_keyed" are the function which are