Was this with a Java 1.4 JVM, or Java 1.5+?
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:
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
>>