[Vm-dev] Re: compiled squeakjs

[Bert Freudenberg]

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.

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.

SqueakJS's "become" is pretty expensive, as is "allObjects". For "allInstances" it depends on whether there are instances in New Space, if not, it's much cheaper. My rationale for that is that these operations are expensive traditionally, so the class library has been designed to avoid them where possible (e.g. OrderedCollection delegating to an array instead of being an array). With Spur making "become" cheap, we may see this stuff sneak back in, and would have to re-evaluate the trade-offs.

For your case, since you're mainly interested in porting a specific application, I think reference counting might work. This would make write-operations more expensive (but you already said that you're willing to pay that), but the cost would be spread over time. In contrast, SqueakJS does no checks at all on writing, making the general case be fast, but paying for that with a pause of a couple hundred milliseconds when it needs to walk the full object memory (e.g. for become).

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4115 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150120/536cd5a2/smime.bin