Hi,
About the use cases: my experience is that most of the time the uses
the in-memory pages (for each listener callback execution, for ajax
requests,...).
Previous version of a page, or previous page is needed when the user
clicks browser back button. Even in this case most of the time the
in-memory cache is hit. Only when the user goes several pages back and
this page is not in-memory then the disk store is used.
So far so good, but...! Even in-memory store contains serialized
versions of the Page, named SerializedPage. This is a struct which
contains
{
sessionId: String,
pageId: int,
data: byte[]
}
so the Page is serialized back and forth when stored in *any*
IPageStore/IDataStore.
This is the current state in Wicket 1.5.
Me and Pedro noticed that IPageStore impl (DefaultPageStore) can be
improved to work with Page instances but we decided to postpone this
optimization for 1.5.0+.
About new String("someLiteral"): I don't remember lately seeing this
code neither in libraries, nor in applications. This constructor
should be used only when the developer explicitly wants this string to
not be interned and stored in the PermGen space, i.e. it will be
stored in the heap space.
Your benchmark test tests exactly this - the heap space.
I'll try the app with MemoryMXBean to see whether the non-heap changes
after deserialization.
I'm not very into Java Serialization but indeed it seems the Strings
are deserialized in the heap. But even in this case they go in the
Eden space, i.e. they are reclaimed soon after.
On Sun, Jul 10, 2011 at 2:37 AM, richard emberson
<[email protected]> wrote:
> I you run the little Java program I included, you will see that
> there is an impact - de-serialized objects take more memory.
>
> Richard
>
> On 07/09/2011 05:23 PM, Igor Vaynberg wrote:
>>
>> string literals are interned by the jvm so they should have a minimal
>> memory impact.
>>
>> -igor
>>
>> On Sat, Jul 9, 2011 at 5:10 PM, richard emberson
>> <[email protected]> wrote:
>>>
>>> Martin,
>>>
>>> The reason I was interested was because it struck me a couple of
>>> days ago that while each Page, tree of Components, is created
>>> many (almost all?) of the non-end-user-generated Strings stored
>>> as instance variables in the tree are shared
>>> between all copies of the Page but that when such a Page is
>>> serialized to disk and then de-serialized, each String becomes its own
>>> copy unique to that particular Page. This means that if an
>>> appreciable number of Pages in-memory are reanimated Pages, then
>>> there could be a bunch of memory being used for all the String
>>> copies.
>>>
>>> In the attached simple Java file (yes, I still write Java when I must)
>>> there are three different ways of creating an array of
>>> Label objects (not Wicket Label) where each Label takes a String:
>>> new Label(some_string)
>>>
>>> The first is to share the same String over all instance of the Label.
>>> new Label(the_string)
>>> The second is to make a copy of the String when creating each
>>> Label;
>>> new Label(new String(the_string))
>>> The third is to create a single Label, serialize it to an array of
>>> bytes and then generate the Labels in the array by de-serialized
>>> the byte array for each Label.
>>>
>>> Needless to say, the first uses the least memory; the label string
>>> is shared by all Labels while the second and third approach
>>> uses more memory. Also, if during the de-serialization process, the
>>> de-serialized String is replaced with the original instance of the
>>> String, then the third approach uses only as much memory as the
>>> first approach.
>>>
>>> No rocket science here, but it does seem to imply that if a
>>> significant number of Pages in-memory are actually reanimated Pages,
>>> then there could be a memory saving by
>>> making de-serialization smarter about possible shared objects.
>>> Even it it is only, say, a 5% saving for only certain Wicket
>>> usage patterns, it might be worth looking into.
>>>
>>> Hence, my question to the masters of Wicket and developers whose
>>> application might fit the use-case.
>>>
>>> Richard
>>>
>>> On 07/09/2011 11:03 AM, Martin Makundi wrote:
>>>>
>>>> Difficult to say ... we have disabled page versioning and se dump
>>>> sessions onto disk every 5 minutes to minimize memory hassles.
>>>>
>>>> But I am no master ;)
>>>>
>>>> **
>>>> Martin
>>>>
>>>> 2011/7/9 richard emberson<[email protected]>:
>>>>>
>>>>> This is a question for Wicket masters and those application builders
>>>>> whose application match the criteria as specified below.
>>>>>
>>>>> [In this case, a Wicket master is someone with a knowledge
>>>>> of how Wicket is being used in a wide spectrum of applications
>>>>> so that they have a feel for what use-cases exist in the real world.]
>>>>>
>>>>> Wicket is used in a wide range of applications with a variety of
>>>>> usage patterns. What I am interested in are those applications where
>>>>> an appreciable number of the pages in memory are pages that had
>>>>> previously been serialized and stored to disk and then reanimated,
>>>>> not found in an in-memory cache and had to be read from disk and
>>>>> de-serialized back into an in-memory page; which is to say,
>>>>> applications with an appreciable number of reanimated pages.
>>>>>
>>>>> Firstly, do such applications exists? These are real-world
>>>>> applications where a significant number of pages in-memory
>>>>> are reanimated pages.
>>>>>
>>>>> For such applications, what percentage of all pages at any
>>>>> given time are reanimated pages?
>>>>> Is it, say, a couple of percent? Two or three in which case its not
>>>>> very significant.
>>>>> Or, is it, say, 50%? Meaning that half of all pages currently in
>>>>> memory had been serialized to disk, flushed from any in-memory cache
>>>>> and then, as needed, de-serialized back into a Page.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Richard
>>>>> --
>>>>> Quis custodiet ipsos custodes
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> --
>>> Quis custodiet ipsos custodes
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> --
> Quis custodiet ipsos custodes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
