This problem could be solved by introducing the ability to remove methods
marked with a particular annotation when some option was enabled and have
them eliminated accordingly.
Imagine the ClassCastChecking and ArrayIndexChecking were done by two
methods on some imaginary helper class used by the gwt runtime.
class GwtRuntime
@CheckClassCast
- checkClassCast
@CheckArrayIndex
- checkArrayIndex
Given that the compiler in this contrived example insert calls to the above
two methods all over the place one could easily remove them if you wanted to
improve performance as per Ray's suggestion.
Pseudo code for the JModVisitor could look like this...
Visit all method target invocations.
if target method has one of the eliminate me annotations then
remove method invocation.
end if
If the actual list of annotations could be set on the command line it would
also allow me to eliminate my own check methods which i might not want in my
super fast production version.
As a side note the problem with asserts is its an all of nothing its quite
difficult / hard to pinpoint that one wants to remove only one type of js
construct as opposed to all. Using different annotations allows one to
categorise and eliminate at will.
On Thu, Nov 13, 2008 at 9:03 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>
> Bruce,
> I'm kinda swamped myself right now, but I can whip something up
> after Thanksgiving. I like John's proposal too, since I like more
> powerful general purpose optimizations, but it seems like a lot more
> work than yours, and given time constraints I'd probably hack in your
> -X proposals. Of course, I'd like to hear any and all objections from
> the GWT team before I start a patch, since there's a difference
> between "potentially unsafe" and "guaranteed to break correct
> programs" :)
>
> -Ray
>
>
> On Tue, Nov 11, 2008 at 12:02 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> > How about we start a convention for -Xunsafe:yyy flags, like
> >
> > -Xunsafe:disableArrayIndexChecks
> > -Xunsafe:disableClassCastChecks
> > -Xunsafe:disableDefensiveCollections
> >
> > then we'd want a roll-up flag like
> >
> > -Xunsafe:all
> >
> > Of course, we'd want to not document these.
> > @Ray: The compiler guys are slammed right now. But if you have anything
> > resembling a patch that could start this pattern, I think that's the only
> > realistic way to get this done in the short term. Also, I'd like to see
> if
> > Scott/Lex/anyone else disagree before we proceeded down this path.
> > On Tue, Nov 11, 2008 at 2:47 PM, Ray Cromwell <[EMAIL PROTECTED]>
> wrote:
> >>
> >> Is there any objection to changing the checkIndex() method in
> >> AbstractList to an assert? I suppose one might want JRE behavior in HM
> >> even if assertions are disabled, but perhaps we could just check
> >> !GWT.isScript() and use if vs assert. I noticed that if you hammer on
> >> ArrayList, a very large number of calls are generated to checkIndex.
> >> Current, about 1.5% of runtime. There's also it's friend, setCheck
> >> too.
> >>
> >> These seem like easy performance wins with very little work, of
> >> course, we want the compiler to continue to get better at well, like
> >> doing range check elimination where it can. :)
> >>
> >> -Ray
> >>
> >> On Tue, Nov 11, 2008 at 7:54 AM, Bruce Johnson <[EMAIL PROTECTED]>
> wrote:
> >> > On Tue, Nov 11, 2008 at 10:51 AM, Isaac Truett <[EMAIL PROTECTED]>
> >> > wrote:
> >> >>
> >> >> > I'm curious what things you're referring to here. Generally, I
> think
> >> >> > we're
> >> >> > pretty open to more checks in hosted mode. As an example, hosted
> mode
> >> >> > always
> >> >> > runs with assertions enabled.
> >> >>
> >> >> More assertions are exactly what I've been hoping for. The one case
> >> >> that's stuck with me was issue 2365. As I understand it, those
> >> >> assertions (and the check method, if only called in assertions) will
> >> >> all be compiled away, so there's no size or performance penalty in
> web
> >> >> mode.
> >> >
> >> > That's exactly right. And as we add new library classes, I anticipate
> >> > we'll
> >> > be doing a lot more assertion checking versus if/then/throw type
> tests.
> >> > This
> >> > is one area where I honestly believe the traditional Java patterns are
> >> > just
> >> > plain wrong: coding that's far too defensive.
> >> > >
> >> >
> >>
> >>
> >
> >
> > >
> >
>
> >
>
--
mP
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
