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

[strk]

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; };
  
  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 love the idea of clueing in the garbage collector!

Me too ! 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.

The GcResource::delete() call will not destroy the thing, but simply pass the 
clue
to the GC.

Just an idea, not sure about the benefit of all of this, compared to the 
trouble.

The other thing, which would generally help adding improvements later would be
a long time old story of using a smart pointer to store GcResources.

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...

Well, enough ideas to keep me up at night. Should really come down before it's 
too late :P

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!