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. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
