It's quit easy to determine if an argument to a checl method has side
effects - if I recall there's a has side effects() ... At worst the
method invocation is removed but the "block" is kept because of the
sideeffects... In the end some statements have been eliminated which
can only help m
The logic would have to be a little more complicated than that, since
the method invocations could have side effects (checkIndex(i++, x=y,
etc)) which would need hoisting.
-Ray
On Thu, Nov 13, 2008 at 3:02 PM, Miroslav Pokorny
<[EMAIL PROTECTED]> wrote:
> This problem could be solved by introdu
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
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 cou
On Tue, Nov 11, 2008 at 3: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
>
> -Xunsa
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 r
Our JRE isn't run in hosted mode, so that shouldn't be an issue.
Let's use the pattern of calling checkIndex within an assert, and having
checkIndex always return true if it doesn't throw.
On Tue, Nov 11, 2008 at 2:47 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>
> Is there any objection to chang
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
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
Maybe John can comment on issue #2365 in particular.
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
> >
> 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
On Tue, Nov 11, 2008 at 10:38 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> > We've been kicking around the idea of an "unsafe but fast" compile for
> > exactly this reason.
>
> I always thought the compile was "unsafe" already.
Only for things that are truly unaffordable, like null checks on
On Tue, Nov 11, 2008 at 10:38 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> > We've been kicking around the idea of an "unsafe but fast" compile for
> > exactly this reason.
>
> I always thought the compile was "unsafe" already. Hasn't the GWT
> philosophy been to perform type safety/bounds/null
That's a great find, Ray.
In terms of ideal product direction, I'd rather consider a flag like that
(at least, one that's documented) as the last resort. Extra options tend to
lead to option-shock, and we don't want people to have to think about things
like that too much.
Instead, I think we ought
> We've been kicking around the idea of an "unsafe but fast" compile for
> exactly this reason.
I always thought the compile was "unsafe" already. Hasn't the GWT
philosophy been to perform type safety/bounds/null checks only in
hosted mode, if at all? Are there many such checks currently left in
We've been kicking around the idea of an "unsafe but fast" compile for
exactly this reason.
OTOH, there are a couple of things we could do to make the type checks
faster even in the short term:
1) Do actual null tracking so as to omit the null check part in many cases.
2) Get away from using type
Seems to be a good idea! I guess it is hard to find an approach that
will cover all the "contract checking" code snippets in the gwt
widgets.
Do you have an idea in mind how to handle this? Annotations?
On 11 Nov., 08:14, "Ray Cromwell" <[EMAIL PROTECTED]> wrote:
> Heads up guys,
>
> I just prof
17 matches
Mail list logo
