Re: [abc] J-LO

Eric Bodden wrote:

>>What do you mean by "went away"? Do you mean the drops
>>disappeared (so you had a consistent upwards trend), or did
>>memory usage stay reasonably constant?
>>
>>
>
>The latter. It stayed around 1-2 MB with no upwards trend, at least for
>the first few hundred iterations.
>
>
Well, even in the fluke run that completed in 76 minutes, the memory
usage stayed pretty constant for the first few hundred iterations, so I
don't think this is a good indication that the spikes have indeed
disappeared. You simply didn't run it long enough to see them.

>>Looking at the paper
>>link you give, I was surprised to find your claim that J-LO
>>shows practically no memory overhead on JHotDraw, since I
>>seem to remember having to provide it with a large heap when
>>I was experimenting with it. My recollections are hazy at
>>best, though...
>>What is the real situation?
>>
>>
>
>If the implementation does what it is intended to do (i.e. there is no
>bug), the memory overhead should be in the order of (size of formula) *
>(number of bindings). That means that when you test with a large number
>of shapes in JHotDraw, you may see a (hopefully linearly) high memory
>consumption. The tests for the SC paper were done with 3 shapes only.
>Hence the consumption stayed so low, I reckon. However, I have never
>found a situation where I had to give it more heap space so far.
>
>
(size of formula) * (number of bindings)? Just like that? Not squared or
to some other power due to iterations?

Be that as it may, the number of potential bindings in JHotDraw is
rather large, and in particular increases linearly over time. Sure, some
of the bindings become invalidated. But suppose not all of the
invalidated bindings were picked up as such. Then we would see an
increase in memory usage over time, probably quite similar to the fluke
graph.

>I will give it another run on cardinal right away and see how far it
>gets by tomorrow morning. Then I should be able to give you more details
>about the actual behaviour.
>
Great. We need to resolve this one way or the other.

- P
Received on Sun Mar 05 11:42:05 2006