On 2012/06/13 23:33:46, cromwellian wrote:
Thomas, I'm a little knee deep in I/O slide stuff at the moment, so maybe
you can
sanity check my thinking here. Let me describe what used to be
happening in the
Json stuff and what I was trying to change it to before 2.5, but
probably didn't
finish.
Essentially, in ProdMode I wanted to run all unboxed values. This is theoretically possible, but can't be made to work without 2 compiler
changes:
1) String is allowed as a JSO, so cast checks to cast String to
JsonString fail
if -XdisableCastChecking is not on
2) JsonNumber and JsonBoolean, backed by primitives in prodmode, can
fail in
conditional checks against != null/null.
To fix these, I started boxing values on fetch, but kept everything
stored raw
so it could be consumed by other JSO code unchanged.
However I noticed the boxing/deboxing code produces significant bloat
from the
getters, because they are inlined and much more frequent.
So a few weeks ago I decided to migrate to a strategy of 'box on store
and stay
boxed', so Json.parse() and put/set calls box the primitives. They are
stay
boxed unless one of the coercion functions is used.
For DevMode, constructing Json* objects gives you JRE implementations
for speed.
However, because a DevMode function can still call a JSNI function
which returns
a pure interface (e.g. JsonObject) both versions can be active, and
therefore,
the code must be defensive for DevMode. I haven't tried it, but I'm
guessing
DevMode handles boxed Number and Boolean properly.
FYI, JsoSplittable in AutoBeans is unfortunately @GwtScriptOnly, which forces you to serialize and deserialize a JSO in DevMode instead of just casting it to a Splittable. So having the Js implementation work in DevMode alongside the "optimized for the JVM" Jre implementation is great!
Ultimately, for ProdMode, maybe in a 2.5.1 release, I want to modify
the
compiler to completely eliminate any boxing at all.
Unless you're going to move your internal apps to this version of elemental, how about keeping the non-optimized "box on get" in 2.5.0, given it'll be "fixed" in 2.5.1? For such an experimental feature, having compatibility with JSOs (retrieved from JSNI, or a JsonpRequestBuilder for instance) seems more important than optimized output; so you can start to code with Elemental in 2.5, and have it optimized with 2.5.1 then. http://gwt-code-reviews.appspot.com/1728806/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
