Re: [Vote] custom serialization seems to work...
But gives it the Deep clone size? If it doesn't it is useless johan On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: I think now that we're dependent on JDK 1.5+, there is a JMX-related sizeof method we can use to find out the exact size of a given object in memory. We might want to switch to that. Eelco Hillenius wrote: On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote: Thats fine. Already thought about it where we let the Objects class look at a setting where you can choose what every you want. But i don't think that is really a choice many people will use. But if they can come up with a better way for serialization and deserialization thats fine with me I just want to make sure we have a fallback for people to use in case we have some unforseen bug in our mechanism or their security environment doesn't allow for some of the things we do or they have some other reason to prefer another (i.e. Java's default) serialization mechanism. We just have to make sure that those 2 methods are called always when we do the clone or save... For example the sizeOf methods should also be altered! I wouldn't have a problem with sizeOf depending on it more directly if there isn't a practical way around it (though I'm sure there is); that's merely a utility whereas serialization for versions is a central piece of the framework. Eelco -- View this message in context: http://www.nabble.com/custom-serialization-seems-to-work...-tf3210889.html#a8938197 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] custom serialization seems to work...
really? i if see how long yourkit needs to compute sometimes to get everything.. then i am curious why it can be soo much faster, but i guess it is easier when on live data with the jvm helping. johan On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: yes. that's my understanding. actual memory consumed by entire graph. Johan Compagner wrote: But gives it the Deep clone size? If it doesn't it is useless johan On 2/13/07, Jonathan Locke [EMAIL PROTECTED] wrote: I think now that we're dependent on JDK 1.5+, there is a JMX-related sizeof method we can use to find out the exact size of a given object in memory. We might want to switch to that. Eelco Hillenius wrote: On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote: Thats fine. Already thought about it where we let the Objects class look at a setting where you can choose what every you want. But i don't think that is really a choice many people will use. But if they can come up with a better way for serialization and deserialization thats fine with me I just want to make sure we have a fallback for people to use in case we have some unforseen bug in our mechanism or their security environment doesn't allow for some of the things we do or they have some other reason to prefer another (i.e. Java's default) serialization mechanism. We just have to make sure that those 2 methods are called always when we do the clone or save... For example the sizeOf methods should also be altered! I wouldn't have a problem with sizeOf depending on it more directly if there isn't a practical way around it (though I'm sure there is); that's merely a utility whereas serialization for versions is a central piece of the framework. Eelco -- View this message in context: http://www.nabble.com/custom-serialization-seems-to-work...-tf3210889.html#a8938197 Sent from the Wicket - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/custom-serialization-seems-to-work...-tf3210889.html#a8945820 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [Vote] custom serialization seems to work...
yes. that's my understanding. actual memory consumed by entire graph. Unfortunately it only counts the current object. That's why the author of that blog proposes his algorithm. Eelco
Re: [Vote] custom serialization seems to work...
I think now that we're dependent on JDK 1.5+, there is a JMX-related sizeof method we can use to find out the exact size of a given object in memory. We might want to switch to that. Eelco Hillenius wrote: On 2/12/07, Johan Compagner [EMAIL PROTECTED] wrote: Thats fine. Already thought about it where we let the Objects class look at a setting where you can choose what every you want. But i don't think that is really a choice many people will use. But if they can come up with a better way for serialization and deserialization thats fine with me I just want to make sure we have a fallback for people to use in case we have some unforseen bug in our mechanism or their security environment doesn't allow for some of the things we do or they have some other reason to prefer another (i.e. Java's default) serialization mechanism. We just have to make sure that those 2 methods are called always when we do the clone or save... For example the sizeOf methods should also be altered! I wouldn't have a problem with sizeOf depending on it more directly if there isn't a practical way around it (though I'm sure there is); that's merely a utility whereas serialization for versions is a central piece of the framework. Eelco -- View this message in context: http://www.nabble.com/custom-serialization-seems-to-work...-tf3210889.html#a8938197 Sent from the Wicket - Dev mailing list archive at Nabble.com.
