Changes between Version 4 and Version 5 of MakeEveryPMCAnObject
- Timestamp:
- 02/01/11 06:18:45 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MakeEveryPMCAnObject
v4 v5 2 2 3 3 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 14 4 == All pmc become an object and attribute indexing system == 5 6 Note: 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. 15 7 16 8 The functionality in object.pmc will move to default.pmc. With this action everything will … … 54 46 [[BR]] 55 47 56 == Core pmcs with fully defined class definition == 48 == ~~Core pmcs with fully defined class definition~~ == 49 50 Note: rejected. We're going with 6model (or something similar) for all PMCs. 57 51 58 52 All core pmcs get a full describing pmcclass object as a … … 94 88 [[BR]] 95 89 96 == Replace vtable ref by ref to class == 90 == ~~Replace vtable ref by ref to class~~ == 91 92 Note: rejected. 6model will mean deep changes to PMCs and objects, so this won't apply. 97 93 98 94 Since all pmc will become an object, there will be a field pointing to the pmcclass object. … … 110 106 [[BR]] 111 107 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 110 Note: This idea is rejected. A generational gc will dtrt here. 111 112 == ~~Get/set attribute~~ == 113 114 Note: rejected, more or less. 6model has a similar way of handling attributes and avoids the pmcproxy. 124 115 125 116 The "get_attr_str","get_attr_keyed","set_attr_str","set_attr_keyed" are the function which are
