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