Groovy is a dynamic language for the Java Virtual Machine.
Groovy topics
The Groovy team contributes the following GSoC ideas.
| Title |
Performance improvements |
| Keywords |
Groovy, Java, performance, dynamic language |
| Description |
This proposal discusses a number of techniques to improve performance of the runtime system of Groovy. It proposes the extension of callsite caching technique to achieve the better performance.
Extending Callsite
Alex Tkachman has implemented the callsite caching technique for speeding up Groovy dispatching process [1]. The result of this improvement makes the current snapshot of Groovy 1.6 be much faster than the 1.5 branches. It is feasible to extend this approach to support faster arithmetic operations by implementing:
- Adaptive callsite; a callsite that can adapt itself with runtime parameters; the idea of this kind of callsite came from class DummyCallsite.
- Runtime generated callsite; An approach to generate specialised callsite classes at runtime will be studied. However, this technique may affect the use of PermGen, which in turn raises OutofMemoryException.
- Primitive arithmetic callsite will be implemented on top of 1) and/or 2).
Fastpath generation, as suggested by Jochen Theodorou [2], is also possible to be implemented with the adaptive callsite for general dispatching cases.
Profiling
Proper profiling may be needed for gathering useful information to implement optimisation techniques. A number of questions need to be investigated for how and where the profiler code would be inserted into callsites.
Evaluation
Micro-benchmarks in the Groovy project will be used to measure performance of the newly developed runtime.
Success Criteria
* Arithmetic performance should be better than the current implementation.* General performance should be better than the current implementation.
Future Work
Full optimisation based on re-definition of class, a JDK 1.6 specific APIs, through the JVMTI agent can also be implemented, if there is a policy to ship Groovy 1.6 separately for Java 6 runtime. To support this approach, the more complex technique like trace compilation will be applied. However, this is a low priority compared with the improvement of existing callsite technique.
|
| Mentor(s) |
Jochen Theodorou (Groovy tech lead) |
| Title |
Scientific Groovy module |
| Keywords |
Groovy, Java, scientific, maths, logic, constraint programming, dynamic language |
| Description |
- Several existing Java libraries cover scientific calculations and problem solvers. For instance, commons-math, choco, JScience are all great libraries that could be used and integrated in a Groovier way using metaprogramming techniques. The goal would be to provide a nice integrated way of using these libraries in Groovy to give the scientific community a tool of choice for their needs.
- A library for symbolic mathematics: coding differentiation, integration. One strategy might be to develop things from 0 (probably funnier) or use existing JVM libraries (more results faster). There is a fantastic example in the python world, SymPy.
|
| Mentor(s) |
Tiago Antao and Guillaume Laforge (Groovy project manager) |
| Title |
Concurrency features built-in |
| Keywords |
Groovy, Java, concurrency, map-reduce, list comprehension, util.concurrent, grid computing, dynamic language |
| Description |
Groovy's metaprogramming and DSL capabilities make it an ideal candidate for expressing complex distributed problems in a natural and readable way, and to leverage our existing multi-core multi-processor architectures. The goal of this module would be to provide interesting Groovy idioms to address concurrency, and distribution problems. |
| Mentor(s) |
Tbd. |
Gant topics
| Title |
Gant Eclipse plugin |
| Keywords |
Gant, Groovy, Eclipse, GUI, build |
| Description |
Gant needs an Eclipse plugin so that it can be used in the same way that Ant and Maven can currently be used in Eclipse. This point is noted in GANT-1. This is a 'from scratch' project as there is currently no plugin at all. The project would involve researching the Ant and Maven plugins to create an architecture and road map for development of the Gant plugin and then to create a first draft implementation of the plugin. |
| Mentor(s) |
Russel Winder |
| Title |
Alternate execution model for Gant |
| Keywords |
Gant, Groovy, build, trees, graphs, data structures |
| Description |
Gant currently works by direct execution of Groovy code and immediate scripting of Ant tasks. This means that all decisions regarding a build have to be taken as they are needed, there is no opportunity for reflection regarding the whole build as happens with Ant, Maven, SCons, Rake, Rant, etc. The alternate mechanism for Gant is to work in two phases instead of one as is currently the case. In the first phase in this alternate model a data structure (almost certainly a graph) would be constructed, then in the second phase the actions required to fulfil the targets would be scheduled and executed. This then gives an opportunity for reflection on the build between phases one and two. A particular issue is to recognize and deal with circular dependencies. |
| Mentor(s) |
Russel Winder |
Template
| Title |
|
| Keywords |
|
| Description |
|
| Mentor(s) |
|
