Thread: synchronized code

synchronized code

From
Felipe Schnack
Date:
  I'm quite worried with the amount of synch'd code in our jdbc driver
code, we all know this is a very costly operation in Java.
  As far as I could see from the sources, the sole objective of these
calls are to avoid two processes accessing the same shared StringBuffer
we use. The strangest thing, IMHO, is that every time we use this
buffer, we are calling setLength(0) or, in plain english, resetting this
buffer. Is just me the paranoid or this isn't helping performance at
all? As I understand java, object creating is a very cheap operation
these days (in the old days it was slow), but synch'ing is VERY
costly...


--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
"Michael Paesold"
Date:
Felipe Schnack <felipes@ritterdosreis.br> wrote:

>   I'm quite worried with the amount of synch'd code in our jdbc driver
> code, we all know this is a very costly operation in Java.
>   As far as I could see from the sources, the sole objective of these
> calls are to avoid two processes accessing the same shared StringBuffer
> we use. The strangest thing, IMHO, is that every time we use this
> buffer, we are calling setLength(0) or, in plain english, resetting this
> buffer. Is just me the paranoid or this isn't helping performance at
> all? As I understand java, object creating is a very cheap operation
> these days (in the old days it was slow), but synch'ing is VERY
> costly...

Sun claims that with Java 1.4, synchronization isn't *that* expensive
anymore. Anyway, object creation has improved, too. Which JVM are most
people using? Probably more people still use 1.3, especially with J2EE. Just
my $0.02.

Regards,
Michael


Re: synchronized code [Viruschecked]

From
"Patric Bechtel"
Date:
On 08 Jan 2003 16:43:11 -0200, Felipe Schnack wrote:

>  I'm quite worried with the amount of synch'd code in our jdbc driver
>code, we all know this is a very costly operation in Java.
>  As far as I could see from the sources, the sole objective of these
>calls are to avoid two processes accessing the same shared StringBuffer
>we use. The strangest thing, IMHO, is that every time we use this
>buffer, we are calling setLength(0) or, in plain english, resetting this
>buffer. Is just me the paranoid or this isn't helping performance at
>all? As I understand java, object creating is a very cheap operation
>these days (in the old days it was slow), but synch'ing is VERY
>costly...

There's no reason to fear about synchronisation since Hotspot anymore. The
lock, as only one process is building it, is definitely less work
than the work the garbage collector has to do in a mark-sweep cycle to
get rid of Stringbuffer over Stringbuffer (which would occur otherwise).
That said, as the syncing is upon a Stringbuffer for EACH statement, and
the statement class threaded use is discouraged anyway, we will probably
never see code really running into this.
As many many string operations are needed throughout the driver, the use
of a sync'ed stringbuffer whenever bigger string operations are made
is very wise and good style. Kudos here to the developer who made this...
The only drawback is, for the developers, that they have to be a bit
cautious with the use of it, not to produce deadlocks; but that's
rather easy, as each and every statement has it's own and the statement
class itself isn't that big.

just my 0.02¬...



sincerely,

Patric Bechtel
IPCON Informationssysteme



Re: synchronized code [Viruschecked]

From
Felipe Schnack
Date:
  Yes, good java programmers use lots of StringBuffers :-)
  But about Statement in threaded use: this is discouraged by the spec
or it isn't actually supported?

On Wed, 2003-01-08 at 17:04, Patric Bechtel wrote:
> On 08 Jan 2003 16:43:11 -0200, Felipe Schnack wrote:
>
> >  I'm quite worried with the amount of synch'd code in our jdbc driver
> >code, we all know this is a very costly operation in Java.
> >  As far as I could see from the sources, the sole objective of these
> >calls are to avoid two processes accessing the same shared StringBuffer
> >we use. The strangest thing, IMHO, is that every time we use this
> >buffer, we are calling setLength(0) or, in plain english, resetting this
> >buffer. Is just me the paranoid or this isn't helping performance at
> >all? As I understand java, object creating is a very cheap operation
> >these days (in the old days it was slow), but synch'ing is VERY
> >costly...
>
> There's no reason to fear about synchronisation since Hotspot anymore. The
> lock, as only one process is building it, is definitely less work
> than the work the garbage collector has to do in a mark-sweep cycle to
> get rid of Stringbuffer over Stringbuffer (which would occur otherwise).
> That said, as the syncing is upon a Stringbuffer for EACH statement, and
> the statement class threaded use is discouraged anyway, we will probably
> never see code really running into this.
> As many many string operations are needed throughout the driver, the use
> of a sync'ed stringbuffer whenever bigger string operations are made
> is very wise and good style. Kudos here to the developer who made this...
> The only drawback is, for the developers, that they have to be a bit
> cautious with the use of it, not to produce deadlocks; but that's
> rather easy, as each and every statement has it's own and the statement
> class itself isn't that big.
>
> just my 0.02¬...
>
>
>
> sincerely,
>
> Patric Bechtel
> IPCON Informationssysteme
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Felipe Schnack
Date:
  Yes... but what got better with JVM 1.4 was synch'ing not object
creation, so you're basically saying I'm correct? :-)
  In tomcat discussion lists, that I'm also in, is quite a common belief
that object creating is cheaper... and they're also worried about 1.3
compatibility (just take a look at java.nio thread some weeks ago)
  Anyway, this is easily benchmarked.

On Wed, 2003-01-08 at 16:53, Michael Paesold wrote:
> Felipe Schnack <felipes@ritterdosreis.br> wrote:
>
> >   I'm quite worried with the amount of synch'd code in our jdbc
driver
> > code, we all know this is a very costly operation in Java.
> >   As far as I could see from the sources, the sole objective of
these
> > calls are to avoid two processes accessing the same shared
StringBuffer
> > we use. The strangest thing, IMHO, is that every time we use this
> > buffer, we are calling setLength(0) or, in plain english, resetting
this
> > buffer. Is just me the paranoid or this isn't helping performance at
> > all? As I understand java, object creating is a very cheap operation
> > these days (in the old days it was slow), but synch'ing is VERY
> > costly...
>
> Sun claims that with Java 1.4, synchronization isn't *that* expensive
> anymore. Anyway, object creation has improved, too. Which JVM are most
> people using? Probably more people still use 1.3, especially with
J2EE. Just
> my $0.02.
>
> Regards,
> Michael
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
"Michael Paesold"
Date:
Felipe Schnack <felipes@ritterdosreis.br> wrote:

>   Is... but what got better with JVM 1.4 was synch'ing not object
> creation, so you're basically saying I'm correct? :-)

I think it depends on the virtual machine, but I'm no expert.

I just had a look at the latest StringBuffer sources. What setLength(0)
does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
I have no idea why it is done, it seems to be very inefficient. Especially
when you think of the fact, that this single StringBuffer will grow,
everytime a bigger string is put into it. It seams that sb.delete(0,
sb.length); is much more efficient. It just resets the internal length
counter?

Any comments?

Regards,
Michael Paesold


Re: synchronized code

From
Felipe Schnack
Date:
  yuck! I think this implementation is kinda gross (can you send me this
source? Just curious). Just imagine using preparedstatements, you will
allocate a big internal buffer (to store the "PREPARE", etc command) and
then just execute much smaller "EXECUTE" calls.
  Well, what we have to decide is what is better:
 - Create and destroy StringBuffer objects. This adds object creation
overhead (as far as I know this isn't a problem) and gc overhead (I have
no idea if it's costly)
 - Continue the way it is, or: use a unique StringBuffer, that is
synchronized in every use (maybe it's better now, but historically a
costly operation, AFAIK) and have its contents reset every time (IMHO a
bad programming pratice - easily someone will forget to do it - and as
pointed out by Michael, not very effective).
  My opinion is quite clear, isn't it?

On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
> Felipe Schnack <felipes@ritterdosreis.br> wrote:
>
> >   Is... but what got better with JVM 1.4 was synch'ing not object
> > creation, so you're basically saying I'm correct? :-)
>
> I think it depends on the virtual machine, but I'm no expert.
>
> I just had a look at the latest StringBuffer sources. What setLength(0)
> does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
> I have no idea why it is done, it seems to be very inefficient. Especially
> when you think of the fact, that this single StringBuffer will grow,
> everytime a bigger string is put into it. It seams that sb.delete(0,
> sb.length); is much more efficient. It just resets the internal length
> counter?
>
> Any comments?
>
> Regards,
> Michael Paesold
>
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Oliver Jowett
Date:
On Wed, Jan 08, 2003 at 07:11:46PM -0200, Felipe Schnack wrote:
>   yuck! I think this implementation is kinda gross (can you send me this
> source? Just curious). Just imagine using preparedstatements, you will
> allocate a big internal buffer (to store the "PREPARE", etc command) and
> then just execute much smaller "EXECUTE" calls.
>   Well, what we have to decide is what is better:
>  - Create and destroy StringBuffer objects. This adds object creation
> overhead (as far as I know this isn't a problem) and gc overhead (I have
> no idea if it's costly)
>  - Continue the way it is, or: use a unique StringBuffer, that is
> synchronized in every use (maybe it's better now, but historically a
> costly operation, AFAIK) and have its contents reset every time (IMHO a
> bad programming pratice - easily someone will forget to do it - and as
> pointed out by Michael, not very effective).
>   My opinion is quite clear, isn't it?

I'm in the process of benchmarking this at the moment (we have similar
decisions to make in our own project). At this point, using a 1.4.0 VM on
Solaris 8, it looks like object allocation is faster than synchronization
with:

  - 1 cpu + server VM + lock contention
  - >1 cpu + server VM
  - client VM

Synchronization is slightly (5%) faster for 1 cpu + server VM + no lock
contention.

Actual numbers to follow when I'm done.

-O

Re: synchronized code

From
Felipe Schnack
Date:
  Interesting information, I just can't understand why in multiprocessor
environments synch'ing is faster. Anyway, I guess would be nice to
benchmark against JDK 1.3... mainly because no arguments using JDK 1.4
will not convince most developers :-)

On Wed, 2003-01-08 at 19:40, Oliver Jowett wrote:
> On Wed, Jan 08, 2003 at 07:11:46PM -0200, Felipe Schnack wrote:
> >   yuck! I think this implementation is kinda gross (can you send me this
> > source? Just curious). Just imagine using preparedstatements, you will
> > allocate a big internal buffer (to store the "PREPARE", etc command) and
> > then just execute much smaller "EXECUTE" calls.
> >   Well, what we have to decide is what is better:
> >  - Create and destroy StringBuffer objects. This adds object creation
> > overhead (as far as I know this isn't a problem) and gc overhead (I have
> > no idea if it's costly)
> >  - Continue the way it is, or: use a unique StringBuffer, that is
> > synchronized in every use (maybe it's better now, but historically a
> > costly operation, AFAIK) and have its contents reset every time (IMHO a
> > bad programming pratice - easily someone will forget to do it - and as
> > pointed out by Michael, not very effective).
> >   My opinion is quite clear, isn't it?
>
> I'm in the process of benchmarking this at the moment (we have similar
> decisions to make in our own project). At this point, using a 1.4.0 VM on
> Solaris 8, it looks like object allocation is faster than synchronization
> with:
>
>   - 1 cpu + server VM + lock contention
>   - >1 cpu + server VM
>   - client VM
>
> Synchronization is slightly (5%) faster for 1 cpu + server VM + no lock
> contention.
>
> Actual numbers to follow when I'm done.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Barry Lind
Date:
Oliver,

What you need to be testing is syncronization vs. object allocation
*and* garbage collection.  How are you testing the overhead that the
garbage collection adds since garbage collection in java by its nature
is something that is async.

Perhaps having a System.gc() call at the end of each test would be
sufficient?

thanks,
--Barry

Oliver Jowett wrote:
> On Wed, Jan 08, 2003 at 07:11:46PM -0200, Felipe Schnack wrote:
>
>>  yuck! I think this implementation is kinda gross (can you send me this
>>source? Just curious). Just imagine using preparedstatements, you will
>>allocate a big internal buffer (to store the "PREPARE", etc command) and
>>then just execute much smaller "EXECUTE" calls.
>>  Well, what we have to decide is what is better:
>> - Create and destroy StringBuffer objects. This adds object creation
>>overhead (as far as I know this isn't a problem) and gc overhead (I have
>>no idea if it's costly)
>> - Continue the way it is, or: use a unique StringBuffer, that is
>>synchronized in every use (maybe it's better now, but historically a
>>costly operation, AFAIK) and have its contents reset every time (IMHO a
>>bad programming pratice - easily someone will forget to do it - and as
>>pointed out by Michael, not very effective).
>>  My opinion is quite clear, isn't it?
>
>
> I'm in the process of benchmarking this at the moment (we have similar
> decisions to make in our own project). At this point, using a 1.4.0 VM on
> Solaris 8, it looks like object allocation is faster than synchronization
> with:
>
>   - 1 cpu + server VM + lock contention
>   - >1 cpu + server VM
>   - client VM
>
> Synchronization is slightly (5%) faster for 1 cpu + server VM + no lock
> contention.
>
> Actual numbers to follow when I'm done.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>



Re: synchronized code

From
Oliver Jowett
Date:
On Wed, Jan 08, 2003 at 01:56:19PM -0800, Barry Lind wrote:
> Oliver,
>
> What you need to be testing is syncronization vs. object allocation
> *and* garbage collection.  How are you testing the overhead that the
> garbage collection adds since garbage collection in java by its nature
> is something that is async.
>
> Perhaps having a System.gc() call at the end of each test would be
> sufficient?

I'm timing total throughput across all threads vs. elapsed real time so GC
should be included. -verbose:gc shows that minor GCs are, in fact, happening
frequently (2-3 per second)

-O

Re: synchronized code

From
"Michael Paesold"
Date:
Felipe Schnack <felipes@ritterdosreis.br> wrote:

>   yuck! I think this implementation is kinda gross (can you send me this
> source? Just curious). Just imagine using preparedstatements, you will
> allocate a big internal buffer (to store the "PREPARE", etc command) and
> then just execute much smaller "EXECUTE" calls.

Well, I am really sorry, just re-read the code. I only fills the rest of the
StringBuffer with '\0' bytes, if the new length is _longer_ than the old. My
mistake. So setLength(0) is not expensive.
Btw. there is a src.zip in any j2sdk distribution that contains pretty much
all the java source code.

I would be very much interested in benchmarks with jdk 1.3, too.

Michael


Re: synchronized code

From
Barry Lind
Date:
Felipe,

Actually in many cases the size of the EXECUTE may be much larger than
the PREPARE.  It all depends on the number, type and size of your bind
variables.  It is very easy to have bytea or text bind variables that
are many times larger than the original query.  It all depends on what
you are doing.

--Barry

Felipe Schnack wrote:
>   yuck! I think this implementation is kinda gross (can you send me this
> source? Just curious). Just imagine using preparedstatements, you will
> allocate a big internal buffer (to store the "PREPARE", etc command) and
> then just execute much smaller "EXECUTE" calls.
>   Well, what we have to decide is what is better:
>  - Create and destroy StringBuffer objects. This adds object creation
> overhead (as far as I know this isn't a problem) and gc overhead (I have
> no idea if it's costly)
>  - Continue the way it is, or: use a unique StringBuffer, that is
> synchronized in every use (maybe it's better now, but historically a
> costly operation, AFAIK) and have its contents reset every time (IMHO a
> bad programming pratice - easily someone will forget to do it - and as
> pointed out by Michael, not very effective).
>   My opinion is quite clear, isn't it?
>
> On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
>
>>Felipe Schnack <felipes@ritterdosreis.br> wrote:
>>
>>
>>>  Is... but what got better with JVM 1.4 was synch'ing not object
>>>creation, so you're basically saying I'm correct? :-)
>>
>>I think it depends on the virtual machine, but I'm no expert.
>>
>>I just had a look at the latest StringBuffer sources. What setLength(0)
>>does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
>>I have no idea why it is done, it seems to be very inefficient. Especially
>>when you think of the fact, that this single StringBuffer will grow,
>>everytime a bigger string is put into it. It seams that sb.delete(0,
>>sb.length); is much more efficient. It just resets the internal length
>>counter?
>>
>>Any comments?
>>
>>Regards,
>>Michael Paesold
>>




Re: synchronized code

From
Oliver Jowett
Date:
On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote:

> Actual numbers to follow when I'm done.

The detailed data (and source) is now at:

  http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt

Summary:

 With no lock contention:
  Client VM: allocation is about twice as fast as synchronizing.
  Server VM: allocation is about 5% slower than synchronizing.

 With lock contention, synchronizing is dramatically slower than allocation
 using either VM type; this effect is worse when multiple CPUs are used.

 There's very little difference between allocating a new buffer each time,
 or reusing an buffer via setLength(0), ignoring synchronization. In some
 cases (e.g. 2 cpus with spare capacity) allocating a new object is faster!

 There's another effect in here somewhere that's generating some noise.
 (compare "no synchronization" to "synchronized buffer" for one thread --
 sometimes the synchronized version is faster, but they're doing the same
 operations other than synchronization so I'd expect it to be always
 slower). Reviewing the code, this may be due to a different cost in
 accessing locals vs. instance fields. If so this will also affect
 the synchronization vs. allocation case.

... but enough benchmarking for one day I think!

-O

Re: synchronized code

From
Felipe Schnack
Date:
  you're right, my mistake
On Wed, 2003-01-08 at 21:19, Barry Lind wrote:
> Felipe,
>
> Actually in many cases the size of the EXECUTE may be much larger than
> the PREPARE.  It all depends on the number, type and size of your bind
> variables.  It is very easy to have bytea or text bind variables that
> are many times larger than the original query.  It all depends on what
> you are doing.
>
> --Barry
>
> Felipe Schnack wrote:
> >   yuck! I think this implementation is kinda gross (can you send me this
> > source? Just curious). Just imagine using preparedstatements, you will
> > allocate a big internal buffer (to store the "PREPARE", etc command) and
> > then just execute much smaller "EXECUTE" calls.
> >   Well, what we have to decide is what is better:
> >  - Create and destroy StringBuffer objects. This adds object creation
> > overhead (as far as I know this isn't a problem) and gc overhead (I have
> > no idea if it's costly)
> >  - Continue the way it is, or: use a unique StringBuffer, that is
> > synchronized in every use (maybe it's better now, but historically a
> > costly operation, AFAIK) and have its contents reset every time (IMHO a
> > bad programming pratice - easily someone will forget to do it - and as
> > pointed out by Michael, not very effective).
> >   My opinion is quite clear, isn't it?
> >
> > On Wed, 2003-01-08 at 18:16, Michael Paesold wrote:
> >
> >>Felipe Schnack <felipes@ritterdosreis.br> wrote:
> >>
> >>
> >>>  Is... but what got better with JVM 1.4 was synch'ing not object
> >>>creation, so you're basically saying I'm correct? :-)
> >>
> >>I think it depends on the virtual machine, but I'm no expert.
> >>
> >>I just had a look at the latest StringBuffer sources. What setLength(0)
> >>does, is to wipe the whole buffer with null-bytes ('\0') in a loop! Although
> >>I have no idea why it is done, it seems to be very inefficient. Especially
> >>when you think of the fact, that this single StringBuffer will grow,
> >>everytime a bigger string is put into it. It seams that sb.delete(0,
> >>sb.length); is much more efficient. It just resets the internal length
> >>counter?
> >>
> >>Any comments?
> >>
> >>Regards,
> >>Michael Paesold
> >>
>
>
>
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Felipe Schnack
Date:
  Well, I still have the same opinion about this issue... but would be
really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the
same machine. I'll try to do it later, I'm downloading the sources.

On Thu, 2003-01-09 at 08:39, Oliver Jowett wrote:
> On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote:
>
> > Actual numbers to follow when I'm done.
>
> The detailed data (and source) is now at:
>
>   http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt
>
> Summary:
>
>  With no lock contention:
>   Client VM: allocation is about twice as fast as synchronizing.
>   Server VM: allocation is about 5% slower than synchronizing.
>
>  With lock contention, synchronizing is dramatically slower than
allocation
>  using either VM type; this effect is worse when multiple CPUs are
used.
>
>  There's very little difference between allocating a new buffer each
time,
>  or reusing an buffer via setLength(0), ignoring synchronization. In
some
>  cases (e.g. 2 cpus with spare capacity) allocating a new object is
faster!
>
>  There's another effect in here somewhere that's generating some
noise.
>  (compare "no synchronization" to "synchronized buffer" for one thread
--
>  sometimes the synchronized version is faster, but they're doing the
same
>  operations other than synchronization so I'd expect it to be always
>  slower). Reviewing the code, this may be due to a different cost in
>  accessing locals vs. instance fields. If so this will also affect
>  the synchronization vs. allocation case.
>
> ... but enough benchmarking for one day I think!
>
> -O
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Felipe Schnack
Date:
  Calling System.gc() don't necessarly executes garbage collecting, it
just gives a "hint" to the garbage collector... anyway, I don't see why
this would add so much overhead (creating lots of objects)

On Wed, 2003-01-08 at 19:59, Oliver Jowett wrote:
> On Wed, Jan 08, 2003 at 01:56:19PM -0800, Barry Lind wrote:
> > Oliver,
> >
> > What you need to be testing is syncronization vs. object allocation
> > *and* garbage collection.  How are you testing the overhead that the
> > garbage collection adds since garbage collection in java by its nature
> > is something that is async.
> >
> > Perhaps having a System.gc() call at the end of each test would be
> > sufficient?
>
> I'm timing total throughput across all threads vs. elapsed real time so GC
> should be included. -verbose:gc shows that minor GCs are, in fact, happening
> frequently (2-3 per second)
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Felipe Schnack
Date:
  I think you should, you know... J2EE, not really old applications

On Thu, 2003-01-09 at 09:06, Oliver Jowett wrote:
> On Thu, Jan 09, 2003 at 08:57:19AM -0200, Felipe Schnack wrote:
> >   Well, I still have the same opinion about this issue... but would be
> > really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the
> > same machine. I'll try to do it later, I'm downloading the sources.
>
> Ok, I'll see if I can fit it in tomorrow (but we're not targetting 1.3
> ourselves, so it's lower priority)
>
> -O
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


Re: synchronized code

From
Barry Lind
Date:
Oliver,

Thanks for your work on this.

However to really get a good idea I think we need to see the results for
other platforms and other jvms.  I would like it if we had data from:
sun 1.4 jvm on Solaris (done)
sun 1.3 jvm on Solaris
sun 1.4 jvm on linux
sun 1.3 jvm on linux
ibm 1.3 jvm on linux
gcj jvm on linux
sun 1.4 jvm on windows
sun 1.3 jvm on windows
ibm 1.3 jvm on windows

(Is there a 1.4 IBM out yet, it has been a while since I looked at the
IBM site).

Does anyone have the time to run this on these other platforms?

thanks,
--Barry




Oliver Jowett wrote:
> On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote:
>
>
>>Actual numbers to follow when I'm done.
>
>
> The detailed data (and source) is now at:
>
>   http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt
>
> Summary:
>
>  With no lock contention:
>   Client VM: allocation is about twice as fast as synchronizing.
>   Server VM: allocation is about 5% slower than synchronizing.
>
>  With lock contention, synchronizing is dramatically slower than allocation
>  using either VM type; this effect is worse when multiple CPUs are used.
>
>  There's very little difference between allocating a new buffer each time,
>  or reusing an buffer via setLength(0), ignoring synchronization. In some
>  cases (e.g. 2 cpus with spare capacity) allocating a new object is faster!
>
>  There's another effect in here somewhere that's generating some noise.
>  (compare "no synchronization" to "synchronized buffer" for one thread --
>  sometimes the synchronized version is faster, but they're doing the same
>  operations other than synchronization so I'd expect it to be always
>  slower). Reviewing the code, this may be due to a different cost in
>  accessing locals vs. instance fields. If so this will also affect
>  the synchronization vs. allocation case.
>
> ... but enough benchmarking for one day I think!
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>




Re: synchronized code

From
Felipe Schnack
Date:
  Yes, that's what I meant... but which are the reasons? Compatibility
must be a preocupation, JDK 1.3 is widely used it, like it or not :-)

On Thu, 2003-01-09 at 18:32, Oliver Jowett wrote:
> On Thu, Jan 09, 2003 at 09:18:18AM -0200, Felipe Schnack wrote:
> >   I think you should, you know... J2EE, not really old applications
>
> I don't understand what you mean here..
>
> We're targetting 1.4 instead of 1.3 for reasons that have nothing to do with
> the availability of J2EE servers, if that's what you meant.
>
> > On Thu, 2003-01-09 at 09:06, Oliver Jowett wrote:
> > > On Thu, Jan 09, 2003 at 08:57:19AM -0200, Felipe Schnack wrote:
> > > >   Well, I still have the same opinion about this issue... but would be
> > > > really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the
> > > > same machine. I'll try to do it later, I'm downloading the sources.
> > >
> > > Ok, I'll see if I can fit it in tomorrow (but we're not targetting 1.3
> > > ourselves, so it's lower priority)
>
> -O
--

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341