Mark Collette wrote:
> Was this with a Java 1.4 JVM, or Java 1.5+?
It was 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:
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.
>
> 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
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>