[squeak-dev] Re: compiled squeakjs

Florin Mateoc florin.mateoc at gmail.com
Tue Jan 20 14:17:38 UTC 2015


On 1/20/2015 5:55 AM, Bert Freudenberg wrote:
> On 20.01.2015, at 08:25, Florin Mateoc <florin.mateoc at gmail.com> wrote:
>> On 1/19/2015 1:03 PM, Florin Mateoc wrote:
>>> The idea for become: goes something like this (I know that standard WeakMaps are not enumerable, but given that
>>> Google/Caja were apparently able to write a WeakMap shim without native support, I hope that code can be used as
>>> inspiration to give us enumerable ones - this would also address the more general requirement for weak
>>> collections/allInstances): assignments, as well as the at:put: and instvarAt:put: primitives, add (if not already
>>> there) to the right-hand side object a WeakMap property "owners". This happens only for non-primitive types. The keys
>>> are the owners and the values are the indexes within the owner where the owned object lives. If there is already a
>>> previous object within the owner at that index, the owner/index pair is removed from the previous object's owners. At
>>> become: time, we iterate the owners and do the replacement
>> And of course, if we did have enumerable WeakMaps, cleaning up of the previous owned object's owners does not need to
>> happen, we can just check if what the owner has at the index is still valid at the time of executing become: or
>> allReferences - this would move some pain to the right/less frequent place.
>>
>> Unfortunately, the shim that I mentioned is a dead end - they just store, as a hidden property, each weakMap value in
>> the corresponding object used as its weakMap key, there is nothing stored in the weakMap itself to be iterated over.
>> I think it's a pity that, for some obscure security scenario, they (ECMAScript) cripple an otherwise very useful
>> feature. They could have offered a secure, non-enumerable version of weak collections in addition to an enumerable one
>> for situations where it does not matter. Oh well, back to the drawing board (or to Bert's object layout :) )
> Yep. Working around the lack of weak collections in JavaScript was why I had to come up with my own memory model. I couldn't simply adopt Dan's, who used a Java weak array in JSqueak/Potato.
>
> I briefly got excited about the new WeakMap support in ES6, but as you discovered, without enumeration they are much weaker (pun intended) than what we have in Smalltalk. At first I thought they were completely useless, since the same could be achieved by adding a property to each object. But beyond that you can bulk-empty the WeakMap, being equivalent to removing that property from all those objects. So essentially WeakMaps are useful as caches that can easily be invalidated. I cannot think of another application.

Well, they also work as an "alreadySeen" collection for recursive operations.

> The *reason* for designing WeakMaps in such a limited way is that the ECMAScript committee thinks garbage collection should be unobservable. No expression in the language should depend on the state of the GC. This gives implementers of the language a lot more freedom in designing their VM.

I am not sure I understand this argument. Indeed, as they say, enumerating weak collections introduce some
indeterminism. So what? Does that make Smalltalk or Java programs in general less deterministic than JavaScript ones?
Obviously one has to take care and work around the possibility that something might or might not be there, but this is
not such a unique situation in programming. As for the vm implementors, I wouldn't know, but did actually implementing
weak references make the vms (various Smalltalk, Java, ActionScript...) take a hit in general performance or complexity?

I think they only thing they "really" cared about was something about security (this is Mark Miller we are talking about
:) ):
"This is necessary to prevent attackers observing the internal behavior of other systems in the environment which share
weakly-mapped objects. Should the number or names of items in the collection be discoverable from the API, even if the
values aren't, WeakMap instances might create a side channel where one was previously not available."

And I don't think this argument holds water, especially since, as I said, they could have offered both secure and
unsecure versions.

Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150120/974ee952/attachment-0001.htm


More information about the Squeak-dev mailing list