Re: [Gnash-dev] Caching synthesized object of primary types

[Richard Wilbur]

On Thu, 2009-12-17 at 14:55 +0100, strk wrote:
> On Thu, Dec 17, 2009 at 01:24:59AM -0700, Richard Wilbur wrote:
> > On Thu, 2009-12-17 at 00:09 +0100, strk wrote:
> > > I was thinking (still on potlatch memory use)
> > > that if we cached the objects synthetized for
> > > primitive data types (string, number, boolan)
> > > we could save a lot of temporary objects allocations.
> >
> > My guess is that this could save both in memory use and execution
> > efficiency.
> 
> I've made some AS tests (sleepless hacking mode on) and found this would
> not be 100% compatible. The test is this:
> 
>   cache_container_1 = '';
>   cache_container_2 = '';
>   str='A string';
>   String.prototype.getCached = function(container) { container.cache = this; 
> };
Did you mean?
String.prototype.getCached = function(container) { container.cached =
this; };
>   
>   str.getCached(cache_container_1);
>   trace(typeof(cache_container_1.cached)); // prints 'object'
>   trace(cache_container_1.cached === cache_container_1.cached); // prints 
> 'true'
>   
>   str.getCached(cache_container_2);
>   trace(typeof(cache_container_2.cached)); // prints 'object'
>   trace(cache_container_2.cached === cache_container_1.cached); // prints 
> 'false'
> 
> The last line finds the temporary objects created on first 'getCached'
> call being different from the one created on second 'getCached' call.
> 
> Now, I dubt anyone would rely on it but don't feel like introducing
> more incompatibilities.... (obfuscated code might even do such
> horrible things intentionally)

I assume this test was run on the PP?  Therefore we wish to replicate
this behaviour, not necessarily improve upon it.

What if we made each cached object a reference to the original object as
long as both are treated in a read-only fashion--lazy creation of
temporary objects.  Then we have the choice whether to call any two
references to the same object equivalent--in this case it looks like the
answer to the equivalence test should be, "No!"

When the original object is changed, we first create a real copy in the
first temporary cached object and redirect all other references at the
new temporary object.  When one of the reference objects is changed, we
remove it from the original object's reference list and then make a real
object with the new value.

A temporary reference object would never have a reference list as
references to it could be resolved back to the original object.

These references could be useful for the Garbage Collector as well.

[...]
> I plan to rename the current GC::collect() to GC::fuzzyCollect(),
> keep GC::collect() for the actual collection cycle and the fuzzy one for
> taking quick decisions on worthness of running the cycle.
> 
> I've committed a patch tonight for ActionDelete and ActionDelete2
> which would be interesting starting point for clueing the GC about the
> probabilities of releasing memory... Didn't take further action now,
> but a kind of plan taking life in my brain goes along the lines of
> adding a GcResource::delete() method which would "give the clue" and
> would be called by those opcodes for a start and eventually by the
> ActionCallMethod and ActionGetProperty when they obtained a
> syntethized (often being a temporary) object to deal with.
> 
[...]
> These pointers could later easily be turned into ref-counted ones to
> check effects of that (most likely those temporary objects won't have
> circular refs at all so might even be simply deleted by refcount 0
> condition).
> Or, these pointers might have a role in implementation of a tri coulor
> GC scheme to reduce cost of GC cycle and thus let it happen *during*
> AS loops...

Interesting ideas for GC improvements.  I look forward to seeing what
becomes of this.  The tri-colour scheme seems like a good heuristic for
improving the efficiency and increasing the activity-level of the GC.
> 
> Well, enough ideas to keep me up at night. Should really come down
> before it's too late :P
Good ideas.  Hope you got some sleep.  Now it's my turn;>.

Richard

signature.asc
Description: This is a digitally signed message part