Proposals for mechanisms to "strip stack information" from compiled output

[Ray Cromwell]

Greetings guys, 

  As part of my work on reducing the output size of compiled permutations, I've created a new polymorphic method inlining patch that changes the way that GWT sets up methods on Javascript objects.  (see the patch here: http://gwt-code-reviews.appspot.com/89810/show)

The old way, looks something like this:

function foo() { ... }
_.foo = foo;

That is, GWT will declare a top level function, and then assign this to a prototype field. The patch changes this (for polymorphic methods only) to look like this:

_.foo = function foo() { ... }

This produces a 2% size reduction (on Showcase) and preserves stack trace information. However, for actual production code, you may wish to strip this information to gain extra size reductions, or just build extra permutations that contain it for debugging or A/B testing.

Changing the declaration to this:

_.foo = function() { ... }

Reduces Showcase by 6% which is a very significant gain. The problem is, what's the best way to control this feature and turn it on and off. There are a couple of options:

1) GWT 2.0 contains a module called EmulateJsStack which is used by GWT to switch on stack emulation for IE browsers. It has a property called compiler.emulatedStack which can be set to true or false. This could be extended for a third value "strip". It seems a little strange however to inherit a module called "EmulateJsStack" and set compiler.emulatedStack = strip.

2) Introduce a new property: compiler.stripStack = true/false that works in parallel. If set to true, the stack will be stripped, regardless of EmulateJsStack settings.

3) Introduce a new property: compiler.stackMode = strip, native, emulated. Setting this to emulated would automatically set compiler.emulatedStack to true. Setting it to native would be the current default, and setting it to strip would be enable the new functionality.

Other options?

-Ray

[Ray Cromwell]

Bump.

[BobV]

Since emulatedStack and stripStack are mutually-exclusive, I'd say to
switch to option number three and use the conditional property setters
to support the old value. Something like:

<define-property name="compiler.stackMode" values="strip, native, emulated" />
<set-property name="compiler.stackMode" value="native" />
<set-property name="compiler.stackMode" value="emulated" >
<when-property-is name="compiler.emulatedStack" value="true" />
</set-property>

Also, we should probably get around to adding a way to deprecate old
deferred-binding properties.

--
Bob Vawter
Google Web Toolkit Team

[Bruce Johnson]

We need to call out some use cases that show how these settings would be used in practice, for posterity if nothing else.

Could you describe how we would handle each of these high-level intents that a developer might have?

A) I want stack traces everywhere that it isn't costly.

B) I want stack traces on every browser possible, and for browsers in which it is costly, I want to only burden a random 2% of those users.

C) I want maximum fidelity stack traces everywhere, even paying for emulation on browsers that have native stack traces, if that's better.

D) I want the smallest possible script size by default, but I'm willing to burdon a random 2% of users to capture stack traces.

If we could write clear rules for each of these scenarios, then it's probably sound and easy enough to understand.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[BobV]

On Wed, Nov 25, 2009 at 9:58 AM, Bruce Johnson <br...@google.com> wrote:
> A) I want stack traces everywhere that it isn't costly.

<!-- This is a derived property that doesn't need a property provider
and indicates that getting a useful stack trace will be expensive -->
<define-property name="stackIsExpensive" values="true,false" />
<set-property name="stackIsExpensive" value="false" />
<set-property name="stackIsExpensive" value="true">
<any>
<when-property-is name="user.agent" value="ie6" />
<when-property-is name="user.agent" value="ie8" />
</any>
</set-property>

<!-- Assuming native is the default value. Since the native stack
isn't useful, optimize for code size -->
<set-property name="stack" value="strip">
<when-property-is name="stackIsExpensive" value="true" />
</set-property>

> B) I want stack traces on every browser possible, and for browsers in which
> it is costly, I want to only burden a random 2% of those users.

<define-property name="inStackExperiment" values="true,false" />
<property-provider name="inStackExperiment">
// Do something with cookies, recalculating value every week
</property-provider>

<set-property name="stack" value="emulated">
<when-property-is name="inStackExperiment" value="true" />
<when-property-is name="stackIsExpensive" value="true" />
</set-property>

<set-property name="stack" value="strip">
<when-property-is name="inStackExperiment" value="false" />
<when-property-is name="stackIsExpensive" value="true" />
</set-property>

> C) I want maximum fidelity stack traces everywhere, even paying for
> emulation on browsers that have native stack traces, if that's better.

<set-property name="stack" value="emulated" />

> D) I want the smallest possible script size by default, but I'm willing to
> burdon a random 2% of users to capture stack traces.

<set-property name="stack" value="strip" />
<!-- Assuming that native stack traces are good enough -->
<set-property name="stack" vaue="native" >
<when-property-is name="inStackExperiment" value="true" />
<when-property-is name="stackIsExpensive" value="false" />
</set-property>
<set-property name="stack" vaue="emulated" >
<when-property-is name="inStackExperiment" value="true" />
<when-property-is name="stackIsExpensive" value="true" />
</set-property>

[Ray Cromwell]

Bob, 

  I love your proposal, if Bruce like's it, I'll go ahead and implement it (perhaps without the A/B testing part? We can leave that as a Wiki entry?)

-Ray

[Bruce Johnson]

@Bob: You rock.

@Ray: I like.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors