> Take a look at SerializableChecker$HandleTable, which I basically
> copied from ObjectOutputStream. That's what you should use instead of
> the hasmap you're using as you're looking for system hash rather then
> what the object thinks it's identity should be like. It's not only way
> cheaper to
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
On 2/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
but isnt string identity guaranteed for equal strings because the jvm pools
them?
so String a=new String("a");
String b=new String("ab").substring(0,1);
b==a
Don't know for 1.5, but this type of code was a sure way to get a
flogging in the 1.
nope that doesn't work
String a=new String("a");
String b=new String("ab").substring(0,1);
b.inter()==a.intern()
that works.
On 2/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 2/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> So i will make it identity equal for all objects except
On 2/13/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
So i will make it identity equal for all objects except String
but isnt string identity guaranteed for equal strings because the jvm pools
them?
so String a=new String("a");
String b=new String("ab").substring(0,1);
b==a
-igor
; >> 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
chanism.
>> >
>> >> 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
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 <[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 give
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.
Yeah but it is nice that sizeOf gives you really the bytes that are
generated why it is done for the second level
Else the 2 numbers don't really match.
Also i think the wicket out/in really gives you a much closer number of what
it also cost in mem..
(when i compare the yourkit object size output
> What do you mean wint traverse parents? The only thing i don't do is the
> traversing and call the read/writeobject
> when they are there.
> But for the rest all the fields are stored that are not static and not
> transient of the complete object.
Cool. I tested a little bit and saw your stuff
Wicket object out/in doesn't have class headers at all.
It just saves the fields. It is not meant for long time persistence also
class changes are not supported
But for cloning pages or saving it for the back button all that doesn't
matter.
if you do this in your example:
B b = new B();
writeObj
I just moved the exception handling for JDK based serialization into
the IObjectStreamFactory so that if you use another implementation
(i.e. your's Johan), that implementation can do the reporting as it
likes.
If you can make some nice exception messages, I'd be happy to test it
a bit (I had som
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 ja
hrm, so the default jdk serialization is also building a toc? interesting,
thats what i wanted to know.
-igor
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> no, this is different
>
> B b=new B(); b.a=new A(); b.aprime=new A();
>
> they are different instances, i am talking about cla
no, this is different
B b=new B(); b.a=new A(); b.aprime=new A();
they are different instances, i am talking about class headers not
references
the way jdk serialization works is that for every class it does something
like this
[class-header classname,etc][fields]
so what i want to know and dont
ldn'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.
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/12/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> hmmm
> so if you have something like this
>
> class A {}
> class B { private A a; private A aprime; }
>
> when you serialize B does it write the class header for A once or twice?
> becau
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 seri
On 2/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
hmm the application should be available
because if we start writing classnames and we have to resolve them
then i want to be able to get the right classloader.
But i gues this can also be done in the constructor of
WicketObjectInputStream (gi
On 2/12/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think that header has the classname so it would be output twice
n
On 2/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > for eelco: you had to disable both methods! (objectToByte and
> byteToObject)
> > For now i enabled both so that it gets tested as much as possible the
> coming
> > few days
>
> Ok,
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think that header has the classname so it would be output twice
no? last time i checked the header was a bit over 100by
hmm the application should be available
because if we start writing classnames and we have to resolve them
then i want to be able to get the right classloader.
But i gues this can also be done in the constructor of
WicketObjectInputStream (give the classloader)
johan
On 2/12/07, Eelco Hillenius
What do you think i have been doing the past weekend!! :)
This is really as fast and as small as we can get. Its almost no overhead
and we only store as less bytes as possible.
Its really almost done (for a few bugs of course)
The only thing that is open now is that new GregorianCalendar() does
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
We jus
custom read/write is supported (only have to fix one bug)
I have no idea what Externalizeable brings you exactly compared to the
read/write objects..
But checking if it implements that interface and then just call those
methods is pretty easy.
johan
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTE
So you want to add a registry of classnames->id and also save that?
(as a TOC prepended to the beginning of the the stream is very hard because
you write as you go further)
But why do that? then you still write the classnames and if we write a
classname
it is a string. So that classname will be w
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> for eelco: you had to disable both methods! (objectToByte and
byteToObject)
> For now i enabled both so that it gets tested as much as possible the
coming
> few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit
well you know, im just playing a devils advocate :)
i guess you are kinda using the codec ideas we discussed - cutting out the
long class header
here is what i would try
i guess right now you are keeping an application map:classname->byte
but what if we do this:
keep an application map:classn
I tried jboss didn't get me anything no speed and size improvement.
when i used JBossOut en In instead of the normal out en in.
I can make it work for clusterings but the bytes will be much greater then i
guess
because i need to write a class name instead of a short.
Of course we could do that o
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > for eelco: you had to disable both methods! (objectToByte and byteToObject)
> > For now i enabled both so that it gets tested as much as possible the coming
> > few days
>
> Ok, we ca
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> for eelco: you had to disable both methods! (objectToByte and byteToObject)
> For now i enabled both so that it gets tested as much as possible the coming
> few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit b
well the fact that it is LGPL is ok, we can rewrite the pieces we need. i
was mainly interested in the ideas they used, they did claim it was 30%
faster? hmm
-igor
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 2/12/07, I
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> for eelco: you had to disable both methods! (objectToByte and byteToObject)
> For now i enabled both so that it gets tested as much as possible the coming
> few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit b
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/12/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> before we start doing all this have you guys tried the jboss serialization
> thing yet?
Yes, and it didn't even remotely work for the project I'm working on.
Furthermore, maybe I'm wrong
There probably are a couple of cases where our code could benefit from
either custom read/writeObject methods or implementing Externalizable.
What are your ideas about that?
Eelco
On 2/12/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
before we start doing all this have you guys tried the jboss serialization
thing yet?
Yes, and it didn't even remotely work for the project I'm working on.
Furthermore, maybe I'm wrong, but it seems that after doing two
initial releases this
before we start doing all this have you guys tried the jboss serialization
thing yet?
the problem, like johan mentioned, is that this wont work across jvms
because he keeps some kind of cache? but then this makes it useless for
clustering. i think whatever solution we come up with needs to work a
for eelco: you had to disable both methods! (objectToByte and byteToObject)
For now i enabled both so that it gets tested as much as possible the coming
few days
Ok, we can keep it in for a few days, but it has to improve quite a
bit before it's ready for real world use.
* Does your code anonym
hmm i get on my machine a bigger leap.
115 seconds agains 90 seconds.
but i think that the synching gets to much time.
johan
On 2/12/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
2nd level with byteoutputstream 53906
2nd level with wicketbyteoutputstream 50350
http session store 37714
Johan
2nd level with byteoutputstream 53906
2nd level with wicketbyteoutputstream 50350
http session store 37714
Johan Compagner wrote:
yes that i know.. I first wanted it to be reliable!
Now the tweaking.
But what happens if you switch in Objects.byteToObject and
objectToByteArray
to the defau
yes that i know.. I first wanted it to be reliable!
Now the tweaking.
But what happens if you switch in Objects.byteToObject and objectToByteArray
to the default ObjectOut en InputStreams?
johan
On 2/12/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
Okay, with current svn version it works. That'
Okay, with current svn version it works. That's the good news. Bad news
is, that second level session store is now quite slower.
cca 50 seconds vs 38 seconds http session store.
-Matej
Johan Compagner wrote:
hmm are you sure you test with the latest code?
i just committed some fixes. Can y
hmm are you sure you test with the latest code?
i just committed some fixes. Can you test with the latest code?
Also look what kind of files are created (what is the filename of a page)
I don't get this at all anymore on my machine. I did get it before i made
the change to a stricter syncing.
f
This is fixed.
I didn't overwrite all the read and write methods.
johan
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Not entirely I'm afraid:
2007-02-11 16:25:47,595 ERROR wicket.protocol.http.FilePageStore -
Error in page save thread
java.lang.RuntimeException: java.lang.reflect.I
But it should be tested, if we disable it then it will never be tested...
for a release (beta) we can disable it but i like to keep it enabled in svn.
johan
On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I've turned that custom streaming off by default. Until we are
absolutely, entire
I've turned that custom streaming off by default. Until we are
absolutely, entirely, utmost sure it works without exceptions we
should not commit it (leaving that line commented is fine by me
though).
Eelco
On 2/11/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Not entirely I'm afraid:
2007-0
Sorry, no luck either, This time i got three expired pages and after
that the test just stopped.
2007-02-12 08:21:25.961::INFO: Logging to STDERR via
org.mortbay.log.StdErrLog
2007-02-12 08:21:26.012::INFO: jetty-6.0.1
2007-02-12 08:21:26.289::INFO: NO JSP Support for /, did not find
org.a
Not entirely I'm afraid:
2007-02-11 16:25:47,595 ERROR wicket.protocol.http.FilePageStore -
Error in page save thread
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at
wicket.util.io.ClassStreamHandler.invokeWriteMethod(ClassStreamHandler.java:523)
at
wi
I runned the App1Test1 in 100 iterations and 10 sessions
with then new wicket object outputstream against the normal one
the page size for this test drops from 32KB to 18KB
Also the test runs +20% quicker then with the normal one.
It runs slower then yesterday currently because i do a lot more sy
51 matches
Mail list logo
