Getting rid of autoboxing?

[Goktug Gokdogan]

I was thinking about autoboxing of numbers when assigned to Object and I started to question if we really need them in Java to JS translation - at least for a subset (i.e. Integer and Double).

Object has only a few methods that we can put into Number.prototype (like we do for String) and all methods to Integer/Double can be converted to static calls then theoretically we can drop most of the java autoboxing code. We can also find similar solutions to calls over java.lang.Number.

Perhaps, I'm missing some corner cases but I really feel like we can find a way to get rid of them at least for the most scenarios. Am I being too naive on this?

[Matthew Dempsky]

To clarify:  You're suggesting we represent java.lang.Double, java.lang.Integer, etc. simply as JavaScript Numbers, instead of representing them as JavaScript Objects like how we do for most other Java java.lang.Objects?

That sounds plausibly okay to me; like you say, we do that for java.lang.String already.

Just making sure you're not suggesting getting rid of the Java language autoboxing functionality; i.e., you don't want to make "Object x = 3.0;" into a compiler error.  That's definitely a no-go in my opinion, since it'll break Java language compatibility.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Goktug Gokdogan]

Yes, I'm only talking about getting rid of the generated code, not breaking java :)

[Ray Cromwell]

I explored that a long time ago when Lightweight Collections were proposed, but it won't work that simply. (Sadly, most of the original discussions on this with the Atlanta team were in Google Wave and forever lost) The reason why it won't work is that there is no way to tell the difference between Integer and Double, Float, Byte, Short, et al. 

Only one boxed type can "own" Number.prototype, so instanceof and equals() checks will fail. Also, toString() and compareTo() might return values that break existing apps.

It is impossible to write a runtime test on a primitive JS number that can distinguish between a Double and a Float, and it is impossible to store a castable type map on a given instance of number.

The only way to make this work would be to ensure that *all such* JS numbers are boxed.

This won't work:

var x  = 42.3;

x.isFloat = true;

This also won't work

var x = Number(42.3);

x.isFloat = true;

because typeof(x) == "number"

This will work

var x = Object(42.3)

x.isFloat = true;

x + 2 => prints 44.3

x.isFloat => prints true

But this is nothing more than making a JSO that holds the number with extra runtime fields.

Leaving all this aside, I don't understand why you're trying to do this in the first place. Java is a language which insists on a difference between the semantics of primitive value types and class based reference types. This will most definitely break DevMode. For interop purposes, just declaring the right return type is better IMHO. If you were to write a game using WebGL that had all the interfaces using boxed types, it would be horrendous performance wise.

Eliminating autoboxing via a hack like this might be plausible, but I think it should be separate from the interop stuff. It's an optimization that has impacts far and wide.

-Ray

On Thu, Aug 1, 2013 at 6:01 PM, Goktug Gokdogan <gok...@google.com> wrote:

[Goktug Gokdogan]

I know this is something beyond interop stuff.

However, in general I don't like the idea of autoboxing being a concern in shaping of any APIs so it started to keep bugging me since our discussion.

I know this will sound controversial but I really wonder if most applications would care if boxed type of Integer and Double were actually act like the same class.

(i.e. instanceOf Integer and instanceOf Double both will return true to same object. So equals will return true when the values are equal even boxing types are different)

Also current implementations of compareTo, toString, hashcode are all compatible so those shouldn't be ok.

I think this can be a good candidate for an opt-in kind of optimization in compiler.

We can quickly experiment with it in Google3 by changing the behavior of equals and instanceof and then see which projects survive :)

Another option is making this change just for Double (i.e. let the Double own Number.prototype). Then anybody who wants numeric performance then can stick with double and safely put into lists, maps, use it in loops without any concerns.

I also wonder if we would have better performance if we were to use js boxing type (ie. new Number(100)) as the boxing type? Perhaps JS VMs perform better if they do the unboxing themselves?

[Goktug Gokdogan]

Resurrecting this.

I talked with Roberto and then Ray yesterday and we think that this is a good idea and this will both improve performance and simplify jsinterop/compiler.

The general idea is to make the boxed types work similar to String so all instance methods will be staticified and instanceof operations will work like typeof x === 'number'. There are other issues we need to solve as well but it looks feasible.

The main drawback is; when somebody does something like list.get(x), if the returned value is number, it will return true to both instanceof Double and instanceof Integer etc.

In practice we don't believe this is going to be an issue and our numerical emulation of java is already has other gotchas.

Ray volunteered to provide us a patch to analyze the impact in google3 and we will go from there.

Let me know what you think.

[Arnaud TOURNIER]

Can that be an option ? So that the user knows what happens consciously, in order to optimize the runtime. I admit, that this would not simplify the jscompiler base code, but would provide the user with another powerful optimization...

Just an idea...

Thanks

Arnaud

[Goktug Gokdogan]

The one of the problems is the boxing makes the support of method overloading, var args, etc. more complicated and much slower in JsInterop. Making it optional is not going to help with those.

I think with the experiment we will have a very good data on the impact of this change, after that we can make a much better educated decision. If the impact is significant then like you said we can look for other options like making it optional.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad2ff664-cde8-45d8-b7da-a75dc677aeba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ray Cromwell]

It could be conditioned on jsinterop being switched on or not, in
general though, more and more compiler switch modes I think encourage
lazy/bad code practices in the ecosystem.

Better would be a "lint"/"checked mode" that throws hard errors in
your app when you do something that violates the assumptions, like
thinking there's a way to tell if something is a float vs a double.

[Jens]

It could be conditioned on jsinterop being switched on or not, in
general though, more and more compiler switch modes I think encourage
lazy/bad code practices in the ecosystem.

Conditioned on jsinterop would really be bad, since all js wrapper libs will soon be based on jsinterop which makes that switch literally always on.

IMHO any optimization that breaks java behavior should be optional and only explicit activated by a project's dev team because the dev team needs to know the implications of these optimizations. 

GWT needs to be very careful with such optimizations as most people choose GWT because they are not that familiar with JS and they expect that all java behaviors carry over to JS once the app is compiled and not just most of them.

Back in the days I lost quite some time figuring out why a GWT-RPC request failed to serialize and it was because browsers had started using sub pixel coordinates and GWT has treated int, float, double the same which caused trouble in a serializer. 

In general I am fine with such optimizations but I would prefer if all such optimizations are turned off by default and there would be a chapter about optimizations in the documentation which describes the implications of such optimizations in more detail, especially for Java devs without lots of JS background knowledge.

-- J.

[Danilo Reinert]

What Jens put is very reasonable and I also believe that such impactful optimizations should be optional and documented that way.

[Goktug Gokdogan]

GWT already not conforms to java from numerical perspective. You can easily leak, for example, non-Integer types disguised as 'int' in the type system. This causes all sorts of surprises for people who ends up hitting them but quite luckily most people/apps doesn't care about it. The proposal mostly expands it to boxed types w/ instanceof behavior which is probably even less likely to cause issues. But regardless, we need to prove/disprove this in practice, then we can discuss it from there.