On 23 January 2013 20:34, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 January 2013 17:27, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. ... For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time.
Wow, very exciting! Thank everyone for the hard work :)
EstebanLM wrote
- ephemerons support.
Is this currently available? If so, does that mean that weak announcements taking a block are now working properly?
no it is not integrated yet. After discussing with Eliot, he recommended to use last object format to denote ephemerons. Existing implementation is a bit hackish way to determine if object is ephemeron. So, before we do such change, assume they are not working yet.
Yes, please. This is the only thing that has kept me from integrating the ephemeron work. We can use instSpec/format #5. The instSpec/formats are 0: zero-fixed-sized pointers (e.g. UndefinedObject) 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) 2: zero-fixed-size variable pointers (e.g. Array) 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState (method,selector)) 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem (list,next,executor) 5. unused 6. variable 32-bit non-pointers (e.g. Float) 7. unused (but should be odd bit for length of format 6 objects in 64-bit system) 8. variable 8-bit non-pointers (e.g. ByteArray, String) 9,10,11 odd bits for length of format 8 objects 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) 13,14,15 odd bits for length of format 12 objects
So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 contain pointers. 7's a really bad choice.
Good.
And I won't bore you with the extension to 64-bits and a 5 bit field.
:) As a tangent.. i looking for a ways to have simpler model where we have only 2 object formats: - objects which fields are pointers - objects which contain no pointers because this is the only thing that matters for VM/GC most of the time. For other contracts, like how to treat pointers (whether they weak or ephemeron or any other kind), we could use a 'marker' object, i.e. a special object stored in first slot of questioned object. So, for example, if a first slot has reference to 'WeakKind' special object, then rest references is held weakly. By analogy, putting 'EphemeronKind' will automatically mark object as ephemeron. So, instead of using bits in header, we using extra slot. The advantage is that we're no longer constrained by the number of bits reserved for object format, and future VM can introduce any other kind, if needed, without need to touch rest. dreams, dreams.. :) -- Best regards, Igor Stasenko.