On 18 June 2012 01:36, Eliot Miranda <[email protected]> wrote:
>
>
> On Sun, Jun 17, 2012 at 7:40 AM, Igor Stasenko <[email protected]> wrote:
>>
>> On 17 June 2012 15:09, Sean P. DeNigris <[email protected]> wrote:
>> >
>> > Igor Stasenko wrote
>> >>
>> >> I bet if you do that, some people will be alienated/antagonized by
>> >> this change
>> > Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in
>> > :)
>> > Like pulling off a BandAid... the best thing to do is pull fast and get
>> > it
>> > over with.
>> >
>> >
>> > Igor Stasenko wrote
>> >>
>> >> As a compromise i would suggest to force people to explicitly tell
>> >> their intent
>> > That would be an improvement... Also, what's the status of this
>> > limitation
>> >
>> > (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html)
>> > :
>> >
>> > when:do: anActionBlock subscription does
>> >> not work weakly, you are constrained to when:send:to
>> >
>> > IIUC it was waiting on ephemerons
>> > (http://forum.world.st/Working-with-weak-announcements-td3305802.html)
>> >
>>
>> yes. we can add Ephemerons at any moment now. But then people should
>> use only VMs built
>> on Jenkins, because Eliot's VMs not support them.
>
>
> I wish you would reconsider and reimplement VM ephemeron support using the
> format field as we discussed not the class hack you've implemented which is
> I think buggy and unsafe.
>
I don't think changing the format will make it less buggy.
The main problem (or perhaps uncertainty) which i faced is the
routines to manage stack/JIT space, which run after usual heap tracing
is done, which not very well fit
with ephemeron strategy, and it won't change if i just use different format.
See the #markPhase:
i inserted
"Process ephemerons"
+++ self processEphemeronsQueue: fullGCFlag.
before following:
"Free unused stack pages. Only safe to free stack pages after all
have been traced. "
fullGCFlag ifTrue: [ self freeUnusedStackPages ].
"Only safe to free any machine code methods after all
stack pages have been traced."
self markAndTraceOrFreeMachineCode: fullGCFlag.
that means that potentially (in some very unlikely situation), if new
ephemeron will be
disovered in #markAndTraceOrFreeMachineCode , it won't be processed as
it should.
I still don't understand why you tracing machine code, because this is
just a cache of corresponding compiled methods, and discovering
references which reachable only via machine code but not via
conventional object memory heap, should actually point to an error in
design.
And that's why by knowing that, i were so bold to put
#processEphemeronsQueue: before that code.
So, if an object format is the only concern, and not the above, i can
just change it (thanks we have unused format #5 ).
--
Best regards,
Igor Stasenko.
