Jay, I've been using this code in production since early June. Works well. I'm still using 1.5 for that particular project, but there's no reason it wouldn't work with 1.6, because the code isn't even aware of GWT, so it's agnostic of versions.
Not ready to release publicly yet, but if you really want it, email me off-forum. Alex On Thu, Jul 2, 2009 at 12:33 PM, jay<jay.gin...@gmail.com> wrote: > > Did anything come of this? Alex -- does your approach work with GWT > 1.6? And, have you decided to contribute this anywhere? I'll > understand if you aren't willing, but I figured it can't hurt to ask. > > jay > > On May 7, 1:24 pm, Alex Epshteyn <alexander.epsht...@gmail.com> wrote: >> Hi Bob, >> >> > Could you provide some numbers in terms of raw and gzipped >> > before/after bytes? >> >> This is the OBF compiled js size of a TypeRacer module before and >> after instrumentation (raw/gz): 382/118 vs. 505/142 which can be >> further reduced by using shortened identifiers instead of method name >> strings (it doesn't make much difference when gzipped, though). >> >> In terms of inlining, I've implemented the optimization of not >> instrumenting simple getters and setters, which are guaranteed not to >> raise an exception. Everything else will probably not be eligible for >> inlining. But I do provide an annotation which you can use to exclude >> your hot methods from instrumentation. >> >> > I looked at implementing "perfect" stack traces as an AST visitor, but >> > decided that the size cost, speed cost for inlining, and potential >> > data-leakage for large apps would outweigh the marginal gain of having >> > line-level resolution in deployed apps. >> >> I'm not sure if that's necessarily the case. However, the capability >> you've implemented may very well be sufficient. I'm looking forward >> to testing out your code when I have more time. >> >> > Those tradeoffs do make sense >> > for development and QA versions of an app, but there was only a >> > limited amount of time allocated for implementing stack traces. >> >> Yes, I can tell you from experience that what I did was pretty hairy >> and definitely took a good amount of time. There are lots of corner >> cases to consider when rewriting a Java AST, as you probably know. >> Just to give a tiny example - you can't insert anything before a >> "super()" statement. But at this point I have them all covered. >> >> I'm not yet sure if I'll be open-sourcing my code. I need to support >> my business, which isn't making much from online ad revenue, and I was >> hoping some of the enterprises using GWT might be happy to pay for my >> stack trace system. There are a few commercial tools in the GWT >> space, such aswww.instantiations.com/GWTDesigner, but I'm not sure >> how successful they are. I'd love to get some feedback from you guys >> about this idea. I can go both ways at this point. >> >> > Your approach sounds complementary to the existing implementation. >> >> That's what I was hoping. >> >> Thanks, >> Alex >> >> >> >> On Thu, May 7, 2009 at 9:50 AM, BobV <b...@google.com> wrote: >> > On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn >> > <alexander.epsht...@gmail.com> wrote: >> >> I'm using static code rewriting at the Java source level to maintain a >> >> virtual stack. It's actually working out very well so far. Getting >> >> surprisingly good results for code size, efficiency, and correctness. >> >> > Could you provide some numbers in terms of raw and gzipped >> > before/after bytes? Also, how does this interact with method and >> > function inlining? >> >> >> I want to decide whether it's worth the effort to continue developing >> >> my system. So my questions are does StackTraceCreator work with all >> >> browsers and is your symbol translation system ready to be used? Are >> >> there any limitations with your approach? Perhaps there is some area >> >> where my technique could provide better information to the programmer? >> >> > StackTraceCreator is invoked in Throwable's initalizer and will >> > extract as much data as the browser provides. On Mozilla, you'll get >> > a full stack trace. On other browsers it crawls the caller chain, but >> > since the caller chain isn't a proper series of activation records, >> > and there's a limitation on reentrant functions. In the end, it >> > provides method-level resolution. The symbol map file has enough data >> > to cook a respectable StackTraceElement that makes IDE integration not >> > unreasonable. >> >> > I looked at implementing "perfect" stack traces as an AST visitor, but >> > decided that the size cost, speed cost for inlining, and potential >> > data-leakage for large apps would outweigh the marginal gain of having >> > line-level resolution in deployed apps. Those tradeoffs do make sense >> > for development and QA versions of an app, but there was only a >> > limited amount of time allocated for implementing stack traces. >> >> > Your approach sounds complementary to the existing implementation. >> >> > -- >> > Bob Vawter >> > Google Web Toolkit Team > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
