On Mon, Jul 11, 2011 at 5:12 PM, richard emberson <[email protected]> wrote: > When you say 10000 times, you set NOS_TIMES to 10000? I mean NOS_TRIALS. > (NOS_TIMES should have been called ARRAY_SIZE). > > Richard > > On 07/11/2011 05:38 AM, Martin Grigorov wrote: >> >> Running the third method (the 'problematic' one) 10000 times shows no >> changes in the PermGen space in VisualVM graphics. >> The value is stable at 7.9Mb. >> >> MemoryMXBean shows that non-heap space increases more than heap space >> but I didn't find any resource explaining what is included in this >> non-heap statistics. >> >> The proof that PermGen is quite stable can be seen with: -verbose:gc >> -XX:+PrintGCDetails >> >> It produces something like: >> [Full GC (System) [PSYoungGen: 0K->0K(76480K)] [PSOldGen: >> 1372K->1372K(174784K)] 1372K->1372K(251264K) [PSPermGen: >> 6746K->6746K(16384K)], 0.0198550 secs] [Times: user=0.01 sys=0.00, >> real=0.02 secs] >> >> Comparing several such outputs shows that PermGen is stable (not >> increasing, not decreasing). >> >> Almost all of the memory allocation happens in the YoungGen and rarely >> in the OldGen. This is normal because Label objects are created and >> then discarded. >> >> On Sun, Jul 10, 2011 at 11:37 AM, Martin Grigorov<[email protected]> >> wrote: >>> >>> 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 >>> >> >> >> > > -- > 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]
