You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jonathan Locke <jo...@gmail.com> on 2007/02/13 05:02:55 UTC
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 <jc...@gmail.com> 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...
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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...
Posted by Johan Compagner <jc...@gmail.com>.
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 <jo...@gmail.com> 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 <jo...@gmail.com> 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 <jc...@gmail.com> 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...
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com> 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 <jc...@gmail.com> 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...
Posted by Johan Compagner <jc...@gmail.com>.
But gives it the Deep clone size?
If it doesn't it is useless
johan
On 2/13/07, Jonathan Locke <jo...@gmail.com> 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 <jc...@gmail.com> 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...
Posted by Johan Compagner <jc...@gmail.com>.
ahh they also walk the complete tree as we do with object ser.
and then call use instrumentation.
johan
On 2/13/07, Eelco Hillenius <ee...@gmail.com> 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.
>
> For 1.3 we're still on JDK 1.4 I'm afraid. But we could hide the
> sizeOf behind a strategy and deliver a single jar (as it needs a
> manifest describing the instrumented class) with the instrumentation
> based implementation.
>
> More:
> http://www.jroller.org/page/maxim?entry=again_about_determining_size_of
>
> Eelco
>
Re: [Vote] custom serialization seems to work...
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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.
For 1.3 we're still on JDK 1.4 I'm afraid. But we could hide the
sizeOf behind a strategy and deliver a single jar (as it needs a
manifest describing the instrumented class) with the instrumentation
based implementation.
More: http://www.jroller.org/page/maxim?entry=again_about_determining_size_of
Eelco