cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: Javaflow - major memory issue
Date Sun, 30 Mar 2008 17:18:29 GMT
>>> Without completely rewriting it the only thing I did was to remove  
>>> the data in the ContinuationContext that is not necessary. I do  
>>> this by an extra call to ContinuationContext.onSuspend() in  
>>> AbstractContinuable since Continuation is not aware of the  
>>> implementation of its context (it's just an Object).
>>>
>>> Please review my changes [1] because I'm not really sure about them.
>> Not a fan of the Collections.synchronizedMap(new HashMap()) change  
>> - but
>
> Just curious, any reason for this? Is it not "as optimized"?

Well, of course you pay a runtime penalty for another method  
invocation ....unless the hotspots is able to optimize that away. Not  
sure.

But it's less about optimization - more about keeping the  
synchronization more visible. But as long as the access to the hashmap  
is simple like it is right now I would not argue about it :)

>> other than that they look OK on the first glance :)
>>> They work for the normal case, but what happens in an error case?  
>>> I can't see what's really going on except that the method is left  
>>> on Continuation.suspend() ... It was very interesting to debug it  
>>> when AbstractContinuable.sendPageAndWait(..) was actually hit twice.
>> :) ...what error case do you mean?
>
> Not sure, originally you proposed to put it into a try finally block.

Just to have it as post condition. You never know.

>>> I guess this handling is different in 2.2. There a clean  
>>> ContinuationContext is created on both callFunction(..) and  
>>> handleContinuation(..).
>> Indeed ...that would be another fix ...porting it from 2.2 :)
>
> That's really beyond what I want to do ;-) Let's leave the good  
> stuff for 2.2.

+1

>> Thanks for looking into that.
>
> It was really interesting to see how a Java method is cut into two  
> pieces. Suddenly the debugger stops stepping, but just leaves the  
> methods. And on the next call it just jumps to the appropriate  
> places in the code. Once you get used to it it's easy to debug. I  
> have never tried it before but now I like it better than flowscript.

Yeah, it's interesting isn't it? :)

cheers
--
Torsten

Mime
View raw message