Ryan Lubke wrote:
> Mark Collette wrote:
>
>> Ahh yes, I missed how this is useful. I was thinking of saving and
>> then restoring, but the reality is, that in a single lifecycle, you
>> restore, then save :)
>>
>> I think that I can accomplish both of our goals, by having my
>> components null out _values at the end of saveState. That way it
>> reuses the array from restoreState, but does not continue holding
>> memory after the lifecycle. Would you be open to my providing a patch
>> for the Mojarra as well? Something along the lines of:
>
> Sure thing.
> You'll need to sign the JCA [1] before we can commit the patch however.
>
> [1]
> http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI#section-JavaServerFacesRI-HowCanIContribute
>
>
> Thanks for catching this.
After looking over the code more, I realised that we don't serialize the
saved state by default, so those Object[]s will still be in memory
anyhow, regardless of whether the component tree references them. So
it's probably not a useful optimisation.
But thanks for walking me through this.
- Mark Collette
>>
>> private Object[] _values;
>>
>> public Object saveState(FacesContext _context) {
>> Object[] values = _values;
>> _values = null;
>> if (values == null) {
>> values = new Object[3];
>> }
>> values[0] = super.saveState(_context);
>> values[1] = footerClass;
>> values[2] = headerClass;
>> return values;
>> }
>>
>> public void restoreState(FacesContext _context, Object _state) {
>> _values = (Object[]) _state;
>> super.restoreState(_context, _values[0]);
>> this.footerClass = (java.lang.String) _values[1];
>> this.headerClass = (java.lang.String) _values[2];
>> }
>>
>>
>> - Mark Collette
>>
>>
>> Ryan Lubke wrote:
>>
>>> Profiling some time ago showed Object[] allocation as a hot spot.
>>> This change reduce the impact of that hotspot.
>>>
>>> The _values will be reused only in the case of the post-back
>>> when restoreState() and saveState() will be called within the same
>>> request.
>>>
>>> And yes, if a state manager is used where the tree itself is stored
>>> in the session, there would be higher memory usage.
>>>
>>> We were trying to tune for the common case.
>>>
>>> Mark Collette wrote:
>>>
>>>> Can someone explain something about state saving to me? This is
>>>> rom HtmlColumn:
>>>>
>>>> private Object[] _values;
>>>>
>>>> public Object saveState(FacesContext _context) {
>>>> if (_values == null) {
>>>> _values = new Object[3];
>>>> }
>>>> _values[0] = super.saveState(_context);
>>>> _values[1] = footerClass;
>>>> _values[2] = headerClass;
>>>> return _values;
>>>> }
>>>>
>>>> public void restoreState(FacesContext _context, Object _state) {
>>>> _values = (Object[]) _state;
>>>> super.restoreState(_context, _values[0]);
>>>> this.footerClass = (java.lang.String) _values[1];
>>>> this.headerClass = (java.lang.String) _values[2];
>>>> }
>>>>
>>>>
>>>> Why make _values be an instance field, instead of just allocating
>>>> it on the stack? Won't the component tree be blown away, so that
>>>> _values isn't being reused, anyway? And if the component tree did
>>>> stick around, wouldn't the standing memory requirements go up, with
>>>> all these Object[] sticking around?
>>>>
>>>> - Mark Collette
>>>>