UEHARA Junji | 1 Mar 15:43 2011
Picon

Re: [groovy-dev] an modification proposal of Trampoline call feature of Groovy 1.8.0

Hi Jochen,
thank you for consideration.

2011/3/1 Jochen Theodorou <blackdrag@...>:
> Am 27.02.2011 12:09, schrieb UEHARA Junji:
>>
>> Hi blackdrag and guys,
>>
>> Sorry for late but I wrote another patch mentioned bellow. attached
>> file name is patch2.
>>
>>
>> http://jira.codehaus.org/browse/GROOVY-4677?focusedCommentId=257893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_257893
>
> Jiji, many thanks for your work.
>
> What is currently missing in your patch to complete the version you have?
> You changed ClosureMetaClass, but ClosureMetaClass is not guranteed to be
> used. If tail calls should work in general, this should work also if the
> Closure has a MetaClassImpl or EMC as class - including tests for that.
> Besides that your patch looks quite good already.

No I haven't touched other MetaClasses.
In my understanding, EMC is used for Closure only under situation where
ExpandoMetaClass.enableGlobally() is called, right?
If so, and in my experience, EMC behavior is like DelegatingMetaClass,
I mean if a method unknown in the EMC called, it pass to ClosureMetaClass.
So I can:

  ExpandoMetaClass.enableGlobally()
(Continue reading)

UEHARA Junji | 1 Mar 15:47 2011
Picon

Re: [groovy-dev] an modification proposal of Trampoline call feature of Groovy 1.8.0

2011/3/1 UEHARA Junji <junji.uehara@...>:
> So I can:
>
>  ExpandoMetaClass.enableGlobally()
>  fact={n,total=1G -> n==0 ? total : call(n-1, n*total)}
>  assert fact.metaClass instanceof ExpandoMetaClass
>  assert fact(10) == 3628800

Oops,

  assert fact(1000)

causes stack overflow. I'm sorry for misunderstanding.
EMC should be considered.

--

-- 
UEHARA Junji

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 1 Mar 17:12 2011
Picon

Re: [groovy-dev] an modification proposal of Trampoline call feature of Groovy 1.8.0

Am 01.03.2011 15:43, schrieb UEHARA Junji:
[...]
> No I haven't touched other MetaClasses.
> In my understanding, EMC is used for Closure only under situation where
> ExpandoMetaClass.enableGlobally() is called, right?
> If so, and in my experience, EMC behavior is like DelegatingMetaClass,
> I mean if a method unknown in the EMC called, it pass to ClosureMetaClass.
> So I can:
>
>    ExpandoMetaClass.enableGlobally()
>    fact={n,total=1G ->  n==0 ? total : call(n-1, n*total)}
>    assert fact.metaClass instanceof ExpandoMetaClass
>    assert fact(10) == 3628800
>
> And I don't know the case MetaClassImple is used for user defined closure.
> Please let me know.

That EMC does not work like this you found out yourself already. 
MetaClassImpl should have that ability, because MetaClassImpl is 
normally the base for a custom meta class out there, It might be a 
closure, but you can still do something along the lines of

fact.metaClass = new MetaclassImpl(fact.class)

And then of course fact(1000) would fail. If it also works with 
MetaClassImpl, it has at least a chance to work in a custom meta class, 
created by the user.

[...]
>> So my idea for this is that we keep the current trampoline version for 1.8
(Continue reading)

Hamlet DArcy | 4 Mar 16:31 2011

[groovy-dev] <at> Canonical, <at> Immutable incomplete parameters

Hi all, 

 <at> Canonical is a composition of  <at> EqualsHashCode,  <at> ToString, and  <at> TupleConstructors. However,
 <at> Canonical has no annotation parameters, while the others have many to fine tune object creation. IMO,
 <at> Canonical should have the union of all of the parameters for the other three. Why is this not so? Should
this be a JIRA ticket? 

 <at> groovy.transform.Immutable is a composition of these three as well, yet it again lacks these annotatio
parameters. Why is this not so? Should this also be a JIRA ticket? 

Thanks, 

--
Hamlet D'Arcy
hamlet.darcy@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Dierk König | 4 Mar 16:32 2011

Re: [groovy-dev] <at> Canonical, <at> Immutable incomplete parameters

+1

Dierk

Am 04.03.2011 um 16:31 schrieb Hamlet DArcy:

> Hi all, 
> 
>  <at> Canonical is a composition of  <at> EqualsHashCode,  <at> ToString, and  <at> TupleConstructors. However,
 <at> Canonical has no annotation parameters, while the others have many to fine tune object creation. IMO,
 <at> Canonical should have the union of all of the parameters for the other three. Why is this not so? Should
this be a JIRA ticket? 
> 
>  <at> groovy.transform.Immutable is a composition of these three as well, yet it again lacks these annotatio
parameters. Why is this not so? Should this also be a JIRA ticket? 
> 
> Thanks, 
> 
> --
> Hamlet D'Arcy
> hamlet.darcy@...
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 

(Continue reading)

Paul King | 4 Mar 21:50 2011
Picon

Re: [groovy-dev] <at> Canonical, <at> Immutable incomplete parameters


At the moment, you can override the default "Canonical" behavior simply by
supplying one of the other more fine-grained annotations, e.g.:

============
import groovy.transform.*
 <at> Canonical
 <at> ToString(includeSuper=true)
class Person extends Date { String first, last }
println new Person('Tom', 'Jones')
// => Person(Tom, Jones, Sat Mar 05 06:47:14 EST 2011)
============

The intention was to back port this capability to  <at> Immutable but only
those aspects that wouldn't break immutability.

Cheers, Paul.

On 5/03/2011 1:31 AM, Hamlet DArcy wrote:
> Hi all,
>
>  <at> Canonical is a composition of  <at> EqualsHashCode,  <at> ToString, and  <at> TupleConstructors. However,
 <at> Canonical has no annotation parameters, while the others have many to fine tune object creation. IMO,
 <at> Canonical should have the union of all of the parameters for the other three. Why is this not so? Should
this be a JIRA ticket?
>
>  <at> groovy.transform.Immutable is a composition of these three as well, yet it again lacks these annotatio
parameters. Why is this not so? Should this also be a JIRA ticket?
>
> Thanks,
(Continue reading)

Pratik | 8 Mar 07:30 2011
Picon

[groovy-dev] High CPU and Memory Usage in Groovy Application


Hi, 

We are using groovy to automate our test executions. We have developed java
library that contains business logic and is used by groovy. 

The groovy script runs in a loop and performs following items 
- Waits for an input. The input is provided by external system at a regular
interval say 10 seconds 
- Upon receiving an input, it performs some operations(which includes calls
to some clouser) 
- Prepares and sends the resposne 
- Waits for an input (step 1) 

Over the time, CPU and memory usage are increased. At some stage, groovy
either crashes with OutOfMemory error or stops processing to further
requests as CPU is exhausted. 

We used JProfiler to investigate the root cause of the problem and found
that much of the heap was occupied by some integer, char and Hashtables. We
do not use Hashtables in our system and we only use a few integer variables.
It was also observed that groovy was making recursive calls to the clouser
but we could not identify which clousers are they. We only make a few
clouser calls and they are not recursive, the depth of our clouser calls are
upto only 2 levels. 

JProfile CPU and Memory images are attached. From the memory usage graph it
can be seen that the objects are constantly increasing into the memory and
are not released. CPU usage graph clearly shows that clousers are called
recursively. I suspect that once a clourser is called, all subsequent
(Continue reading)

Jochen Theodorou | 8 Mar 10:21 2011
Picon

Re: [groovy-dev] High CPU and Memory Usage in Groovy Application

Am 08.03.2011 07:30, schrieb Pratik:
> Hi,
>
> We are using groovy to automate our test executions. We have developed java
> library that contains business logic and is used by groovy.
>
> The groovy script runs in a loop and performs following items
> - Waits for an input. The input is provided by external system at a regular
> interval say 10 seconds
> - Upon receiving an input, it performs some operations(which includes calls
> to some clouser)
> - Prepares and sends the resposne
> - Waits for an input (step 1)
>
> Over the time, CPU and memory usage are increased. At some stage, groovy
> either crashes with OutOfMemory error or stops processing to further
> requests as CPU is exhausted.
>
> We used JProfiler to investigate the root cause of the problem and found
> that much of the heap was occupied by some integer, char and Hashtables. We
> do not use Hashtables in our system and we only use a few integer variables.
> It was also observed that groovy was making recursive calls to the clouser
> but we could not identify which clousers are they. We only make a few
> clouser calls and they are not recursive, the depth of our clouser calls are
> upto only 2 levels.

two doCall methdos appearing is probably because you have a closure like 
this:

def bar = { ... }
(Continue reading)

Dimitar Dimitrov | 8 Mar 10:38 2011
Picon

[groovy-dev] Re: High CPU and Memory Usage in Groovy Application

Pratik, looking at your CPU profile screenshot, I can see invocation counts,
which means you've been using instrumentation CPU profiling. This has the
effect to make fast methods to appear the bottleneck (as the profiler
overhead is constant regardless of how fast the method is). Please try again
with sampling and let us know whether you see any difference.

From your memory profile screenshot, I can see that the integers in question
take 12mb. That is certainly strange, but as a temporary measure you can try
increasing the JVM heap-size and see if it gets any better (for example
-Xmx512m).

--
View this message in context: http://groovy.329449.n5.nabble.com/High-CPU-and-Memory-Usage-in-Groovy-Application-tp3413568p3413718.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Guillaume Laforge | 8 Mar 11:46 2011
Picon

[groovy-dev] RC-2 tomorrow

Hi developers,


Besides the usual bug fixes we're adding in the RC, so far nothing really blocker has been detected.
That would be great if we could all try our respective applications / tools / etc to see if they work fine with Groovy's 1.8 branch.

We're going to release an RC-2 tomorrow, if all goes well.
Hopefully, this will be the last RC before the final release in a week or two.

Thanks for your help and for your attention!

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Gmane