Re: j2s-development] gwt groups post

[Zhou R. <jo...@sj...>]

No, we already have Eclipse Java AST which is much more robust than 
their JS AST. We can directly design our linker in Java level not in 
generated JavaScript level.

In my opinion, Dojo is JavaScript for Java, while Java2Script is Java to 
JavaScript. These two toolkits see things differently.

Soheil Hassas Yeganeh wrote:
> I mean the same thing.
> I mean we can just their javascript parser implemented in jslink, to
> build the graph model and then optimize the code, but i really doubt
> about the license whether we can change the code and distribute it or
> not!
> They have JS AST, and I think we can use it as the graph model or call
> hierarchy in the project.
> Regards,
> Soheil
>
> On 10/17/06, Zhou Renjian <jo...@sj...> wrote:
>   
>> When I first met the concept of Dojo js linker, I didn't think it has
>> the capability to link things correctly for the generated *.js of
>> Java2Script compiler. It's something.like GNU linker won't be able to
>> link those *.obj generated by MSVC compiler.
>>
>> But their algorithm may be excellent. And maybe later I should take a
>> study on it.
>>
>> By the way, JavaScript now has its compiler, linker, and executable
>> output (?), simulator(?), maybe later VM, workbench, ... It seems that
>> JavaScript is over-used according the original design of Brendan.
>>
>>
>> Soheil Hassas Yeganeh wrote:
>>     
>>> Ok I got the problem.
>>> Did you see jslinker that AOL has donated to the Dojo toolkit ? For
>>> unreachable code or any other things like this, its possible to use
>>> their linker. But I really doubt about the license.
>>> The jslinker svn repository is available at
>>> http://svn.dojotoolkit.org/dojo/trunk/tools/jslinker
>>>
>>> Regards,
>>> Soheil
>>> On 10/17/06, Zhou Renjian <jo...@sj...> wrote:
>>>
>>>       
>>>> Soheil Hassas Yeganeh wrote:
>>>>
>>>>         
>>>>> Hi Zhou,
>>>>>
>>>>> I doubt about the graph model.
>>>>> In Clazz.searchAndExecuteMethod, that was really very slow, you'd done
>>>>> a lot of performance enhancing works. The most important change you'd
>>>>> made is a cache for methods. After the first call to method
>>>>> invocation, Clazz will cache it and do not search again for the same
>>>>> method invocation. So, after the first call, methods are cached and
>>>>> perform faster.
>>>>> So, what does graph model do for us? Is it just a compile time cache?
>>>>> like the hotspot! or any other enhancement you mean ?
>>>>>
>>>>> Regards,
>>>>> Soheil
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> I just mean reducing the *.js file size.
>>>>
>>>> The call graph concept is about something that how wide the application
>>>> can branch its method calls to. For example, if there are a public
>>>> method M in classs C, by current Java2Script compiler, method M in class
>>>> C will be compiled into JavaScript even the method M will never be
>>>> called by application. But in GWT compiler, if method M are not reached
>>>> by application, GWT compiler won't generate JavaScript for method M. So
>>>> such a call graph algorithm will result in smaller *.js file size.
>>>> Smaller file size may decrease the time needed between client and
>>>> server. And browser initializing method blocks and J2SClazz simulator
>>>> registering method for a class also require CPU time. So in all, by such
>>>> call graph algorithm, performance should be improved.
>>>>
>>>> The above call graph algorithm is a compile time algorithm, nothing
>>>> about hotspot.
>>>>
>>>> In current Java2Script compiler and J2SClazz simulator, they are twisted
>>>> with each other tightly. It seemed that I left too much works on
>>>> JavaScript's Clazz#searchAndExecuteMethod and resulted in a very bad
>>>> performance after all. Maybe the compiler should do more works so
>>>> simulator can do less works to improve performance. That would be a
>>>> right way for further improvement.
>>>>
>>>> And actually there should be a trade-off between compiler and simulator.
>>>> The more we rely on compiler, the fewer information simulator gets, and
>>>> maybe faster will the application run.
>>>>
>>>>
>>>>