You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2016/06/09 17:28:20 UTC
Java default options in ant targets
Hi,
I was reading "Java Concurrency in Practice" (again!) when I (again!) stumbled upon the 6th footnote p. 38 (my edition is from 2011)
You can find a summary at https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice :
\u201cDebugging tip: For server applications, be sure to always specify the
-server JVM command line switch when invoking the JVM, even for
development and testing. The server JVM performs more optimization than
the client JVM, such as hoisting variables out of a loop that are not
modified in the loop; code that might appear to work in the development
environment (client JVM) can break in the deployment environment (server
JVM)...(more explanation and examples)\u201d
Since this book was written in 2006 for Java 5, I checked what the situation is with Java 8
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
Oracle says
\u201cSince Java SE 5.0, with the exception of 32-bit Windows, the server VM will automatically be selected on server-class machines. The definition of a
server-class machine may change from release to release, so please check the appropriate ergonomics document for the definition for your release. For
5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <http://www.oracle.com/technetwork/java/ergo5-140223.html>.\u201d
Hence Sokolenko's comment:
\u201cThough this option is implicitely enabled for x64 virtual machines, it
still makes sense to use it as according to documentation behaviour
maybe changed in the future.\u201d
So this is still true and I wonder if we should not add this option (and some others, see Sokolenko's link above) in some ant targets like "start"
Opinions?
Jacques
Re: Java default options in ant targets
Posted by Jacques Le Roux <ja...@les7arts.com>.
Irrelevant about Brian Goetz's footnote? I'm not sure with Java 8, but I guess it's still true, that's really in the foundation of the compiler
Also maybe a look at the other options?
Jacques
Le 10/06/2016 � 09:46, Jacopo Cappellato a �crit :
> I don't have a strong opinion because, as you said, in most cases the flag
> will be irrelevant.
>
> Jacopo
>
> On Thu, Jun 9, 2016 at 7:28 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi,
>>
>> I was reading "Java Concurrency in Practice" (again!) when I (again!)
>> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>>
>> You can find a summary at
>> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
>> :
>>
>> \u201cDebugging tip: For server applications, be sure to always specify the
>> -server JVM command line switch when invoking the JVM, even for
>> development and testing. The server JVM performs more optimization than
>> the client JVM, such as hoisting variables out of a loop that are not
>> modified in the loop; code that might appear to work in the development
>> environment (client JVM) can break in the deployment environment (server
>> JVM)...(more explanation and examples)\u201d
>>
>> Since this book was written in 2006 for Java 5, I checked what the
>> situation is with Java 8
>>
>> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>>
>> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>>
>> Oracle says
>>
>> \u201cSince Java SE 5.0, with the exception of 32-bit Windows, the server VM
>> will automatically be selected on server-class machines. The definition of
>> a server-class machine may change from release to release, so please check
>> the appropriate ergonomics document for the definition for your release.
>> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
>> http://www.oracle.com/technetwork/java/ergo5-140223.html>.\u201d
>>
>> Hence Sokolenko's comment:
>>
>> \u201cThough this option is implicitely enabled for x64 virtual machines, it
>> still makes sense to use it as according to documentation behaviour
>> maybe changed in the future.\u201d
>>
>> So this is still true and I wonder if we should not add this option (and
>> some others, see Sokolenko's link above) in some ant targets like "start"
>>
>> Opinions?
>>
>> Jacques
>>
>>
Re: Java default options in ant targets
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
I don't have a strong opinion because, as you said, in most cases the flag
will be irrelevant.
Jacopo
On Thu, Jun 9, 2016 at 7:28 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi,
>
> I was reading "Java Concurrency in Practice" (again!) when I (again!)
> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>
> You can find a summary at
> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
> :
>
> “Debugging tip: For server applications, be sure to always specify the
> -server JVM command line switch when invoking the JVM, even for
> development and testing. The server JVM performs more optimization than
> the client JVM, such as hoisting variables out of a loop that are not
> modified in the loop; code that might appear to work in the development
> environment (client JVM) can break in the deployment environment (server
> JVM)...(more explanation and examples)”
>
> Since this book was written in 2006 for Java 5, I checked what the
> situation is with Java 8
>
> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>
> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>
> Oracle says
>
> “Since Java SE 5.0, with the exception of 32-bit Windows, the server VM
> will automatically be selected on server-class machines. The definition of
> a server-class machine may change from release to release, so please check
> the appropriate ergonomics document for the definition for your release.
> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
> http://www.oracle.com/technetwork/java/ergo5-140223.html>.”
>
> Hence Sokolenko's comment:
>
> “Though this option is implicitely enabled for x64 virtual machines, it
> still makes sense to use it as according to documentation behaviour
> maybe changed in the future.”
>
> So this is still true and I wonder if we should not add this option (and
> some others, see Sokolenko's link above) in some ant targets like "start"
>
> Opinions?
>
> Jacques
>
>
Re: Java default options in ant targets
Posted by Taher Alkhateeb <sl...@gmail.com>.
Agreed, it shows you how scary threads are. I remember the first time I
read it i went like ... damn i've been programming explosives and mine
fields for years without even knowing it.
On Jun 10, 2016 8:34 PM, "Jacopo Cappellato" <
jacopo.cappellato@hotwaxsystems.com> wrote:
> On Thu, Jun 9, 2016 at 7:28 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Hi,
> >
> > I was reading "Java Concurrency in Practice" (again!)...
>
>
> By the way, that book is great
>
> Jacopo
>
Re: Java default options in ant targets
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Thu, Jun 9, 2016 at 7:28 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi,
>
> I was reading "Java Concurrency in Practice" (again!)...
By the way, that book is great
Jacopo
Re: Java default options in ant targets
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 10/06/2016 � 13:41, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> I don't have a strong opinion either way. If you think it improves things
> that I don't see a reason why not to add it.
>
> However, I'm not sure what you mean by correctness? The difference between
> -server and -client as far as I understood it has to do with JIT and memory
> management. Essentially you have more overhead and slower startup time in
> -server to allow for better optimization of the application as a whole. I'm
> not sure how this relates to correctness?
Essentially yes, but this Brian Goetz's tip is about variable visibility (with eg volatile) and difference between a server and a client machine. Here
is the complete Brian Goetz's footnote http://tinyurl.com/hgxw9af
In the link you provided (recent since it's Java 8) there are no mentions of Win 32, only Windows.
I work on a Win7 machine which, despite having 4 cores and 16GB is still, considered a "client VM".
So I could get caught by the "Brian Goetz's footnote", others in the same situation than me could also.
I'll later check the other parameters Sokolenko suggests...
Thanks to care :)
Jacques
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Jun 10, 2016 at 2:33 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Taher,
>>
>> That's right at the moment. The point, as Sokolenko made it, is this is
>> not set in stone and could be changed later. It's still not a strong
>> argument I agree, but note that what initially worried me is not
>> performance but correctness: the Brian Goetz's footnote.
>>
>> Also, I put the Sokolenko link and a title with a plural to options
>> because I think we should also check the other options he suggests. Even if
>> I agree, that most of the time it's not a good idea to change the default
>> parameters
>>
>> So back to the main subject, really the correctness aspect is worrying,
>> don't you think so? Maybe it's not longer an issue with Java 8, but I did
>> not search about that...
>>
>> Jacques
>>
>> Le 10/06/2016 � 09:40, Taher Alkhateeb a �crit :
>>
>>> Hi Jacques,
>>>
>>> So it seems for Oracle's JVM the only place where this makes an impact is
>>> in Windows 32 bit architectures.
>>>
>>> I am not sure, but I think it would be better not to pass the flag. Why?
>>> Because the documentation provided by Oracle states that if you omit
>>> -server then the JVM will decide based on hardware spects, more
>>> specificailly: "For Java SE 6, the definition of a *server-class* machine
>>> is one with at least 2 CPUs and at least 2GB of physical memory. "
>>> Reference below with grid.
>>>
>>> http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
>>>
>>> So if you omit the -server flag on an old piece of hardware, then it will
>>> consider it a client. and the main difference between client and server
>>> has
>>> to do with the JIT compiler and startup time vs memory management (server
>>> has more over head but more optimization long term). It makes sense not to
>>> consider old hardware as server to avoid the overhead.
>>>
>>> The only exception, again, is windows 32. Again not sure but I suspect we
>>> do not have a lot of new hardware Windows 32 servers running OFBiz, but I
>>> could be wrong of course.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Thu, Jun 9, 2016 at 8:28 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi,
>>>> I was reading "Java Concurrency in Practice" (again!) when I (again!)
>>>> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>>>>
>>>> You can find a summary at
>>>> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
>>>> :
>>>>
>>>> \u201cDebugging tip: For server applications, be sure to always specify the
>>>> -server JVM command line switch when invoking the JVM, even for
>>>> development and testing. The server JVM performs more optimization than
>>>> the client JVM, such as hoisting variables out of a loop that are not
>>>> modified in the loop; code that might appear to work in the development
>>>> environment (client JVM) can break in the deployment environment (server
>>>> JVM)...(more explanation and examples)\u201d
>>>>
>>>> Since this book was written in 2006 for Java 5, I checked what the
>>>> situation is with Java 8
>>>>
>>>>
>>>> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>>>>
>>>>
>>>> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>>>>
>>>> Oracle says
>>>>
>>>> \u201cSince Java SE 5.0, with the exception of 32-bit Windows, the server VM
>>>> will automatically be selected on server-class machines. The definition
>>>> of
>>>> a server-class machine may change from release to release, so please
>>>> check
>>>> the appropriate ergonomics document for the definition for your release.
>>>> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
>>>> http://www.oracle.com/technetwork/java/ergo5-140223.html>.\u201d
>>>>
>>>> Hence Sokolenko's comment:
>>>>
>>>> \u201cThough this option is implicitely enabled for x64 virtual machines, it
>>>> still makes sense to use it as according to documentation behaviour
>>>> maybe changed in the future.\u201d
>>>>
>>>> So this is still true and I wonder if we should not add this option (and
>>>> some others, see Sokolenko's link above) in some ant targets like "start"
>>>>
>>>> Opinions?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
Re: Java default options in ant targets
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
I don't have a strong opinion either way. If you think it improves things
that I don't see a reason why not to add it.
However, I'm not sure what you mean by correctness? The difference between
-server and -client as far as I understood it has to do with JIT and memory
management. Essentially you have more overhead and slower startup time in
-server to allow for better optimization of the application as a whole. I'm
not sure how this relates to correctness?
Regards,
Taher Alkhateeb
On Fri, Jun 10, 2016 at 2:33 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Taher,
>
> That's right at the moment. The point, as Sokolenko made it, is this is
> not set in stone and could be changed later. It's still not a strong
> argument I agree, but note that what initially worried me is not
> performance but correctness: the Brian Goetz's footnote.
>
> Also, I put the Sokolenko link and a title with a plural to options
> because I think we should also check the other options he suggests. Even if
> I agree, that most of the time it's not a good idea to change the default
> parameters
>
> So back to the main subject, really the correctness aspect is worrying,
> don't you think so? Maybe it's not longer an issue with Java 8, but I did
> not search about that...
>
> Jacques
>
> Le 10/06/2016 à 09:40, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> So it seems for Oracle's JVM the only place where this makes an impact is
>> in Windows 32 bit architectures.
>>
>> I am not sure, but I think it would be better not to pass the flag. Why?
>> Because the documentation provided by Oracle states that if you omit
>> -server then the JVM will decide based on hardware spects, more
>> specificailly: "For Java SE 6, the definition of a *server-class* machine
>> is one with at least 2 CPUs and at least 2GB of physical memory. "
>> Reference below with grid.
>>
>> http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
>>
>> So if you omit the -server flag on an old piece of hardware, then it will
>> consider it a client. and the main difference between client and server
>> has
>> to do with the JIT compiler and startup time vs memory management (server
>> has more over head but more optimization long term). It makes sense not to
>> consider old hardware as server to avoid the overhead.
>>
>> The only exception, again, is windows 32. Again not sure but I suspect we
>> do not have a lot of new hardware Windows 32 servers running OFBiz, but I
>> could be wrong of course.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Thu, Jun 9, 2016 at 8:28 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Hi,
>>>
>>> I was reading "Java Concurrency in Practice" (again!) when I (again!)
>>> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>>>
>>> You can find a summary at
>>> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
>>> :
>>>
>>> “Debugging tip: For server applications, be sure to always specify the
>>> -server JVM command line switch when invoking the JVM, even for
>>> development and testing. The server JVM performs more optimization than
>>> the client JVM, such as hoisting variables out of a loop that are not
>>> modified in the loop; code that might appear to work in the development
>>> environment (client JVM) can break in the deployment environment (server
>>> JVM)...(more explanation and examples)”
>>>
>>> Since this book was written in 2006 for Java 5, I checked what the
>>> situation is with Java 8
>>>
>>>
>>> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>>>
>>>
>>> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>>>
>>> Oracle says
>>>
>>> “Since Java SE 5.0, with the exception of 32-bit Windows, the server VM
>>> will automatically be selected on server-class machines. The definition
>>> of
>>> a server-class machine may change from release to release, so please
>>> check
>>> the appropriate ergonomics document for the definition for your release.
>>> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
>>> http://www.oracle.com/technetwork/java/ergo5-140223.html>.”
>>>
>>> Hence Sokolenko's comment:
>>>
>>> “Though this option is implicitely enabled for x64 virtual machines, it
>>> still makes sense to use it as according to documentation behaviour
>>> maybe changed in the future.”
>>>
>>> So this is still true and I wonder if we should not add this option (and
>>> some others, see Sokolenko's link above) in some ant targets like "start"
>>>
>>> Opinions?
>>>
>>> Jacques
>>>
>>>
>>>
>
Re: Java default options in ant targets
Posted by Jacques Le Roux <ja...@les7arts.com>.
Taher,
That's right at the moment. The point, as Sokolenko made it, is this is not set in stone and could be changed later. It's still not a strong argument
I agree, but note that what initially worried me is not performance but correctness: the Brian Goetz's footnote.
Also, I put the Sokolenko link and a title with a plural to options because I think we should also check the other options he suggests. Even if I
agree, that most of the time it's not a good idea to change the default parameters
So back to the main subject, really the correctness aspect is worrying, don't you think so? Maybe it's not longer an issue with Java 8, but I did not
search about that...
Jacques
Le 10/06/2016 � 09:40, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> So it seems for Oracle's JVM the only place where this makes an impact is
> in Windows 32 bit architectures.
>
> I am not sure, but I think it would be better not to pass the flag. Why?
> Because the documentation provided by Oracle states that if you omit
> -server then the JVM will decide based on hardware spects, more
> specificailly: "For Java SE 6, the definition of a *server-class* machine
> is one with at least 2 CPUs and at least 2GB of physical memory. "
> Reference below with grid.
>
> http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
>
> So if you omit the -server flag on an old piece of hardware, then it will
> consider it a client. and the main difference between client and server has
> to do with the JIT compiler and startup time vs memory management (server
> has more over head but more optimization long term). It makes sense not to
> consider old hardware as server to avoid the overhead.
>
> The only exception, again, is windows 32. Again not sure but I suspect we
> do not have a lot of new hardware Windows 32 servers running OFBiz, but I
> could be wrong of course.
>
> Regards,
>
> Taher Alkhateeb
>
> On Thu, Jun 9, 2016 at 8:28 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi,
>>
>> I was reading "Java Concurrency in Practice" (again!) when I (again!)
>> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>>
>> You can find a summary at
>> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
>> :
>>
>> \u201cDebugging tip: For server applications, be sure to always specify the
>> -server JVM command line switch when invoking the JVM, even for
>> development and testing. The server JVM performs more optimization than
>> the client JVM, such as hoisting variables out of a loop that are not
>> modified in the loop; code that might appear to work in the development
>> environment (client JVM) can break in the deployment environment (server
>> JVM)...(more explanation and examples)\u201d
>>
>> Since this book was written in 2006 for Java 5, I checked what the
>> situation is with Java 8
>>
>> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>>
>> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>>
>> Oracle says
>>
>> \u201cSince Java SE 5.0, with the exception of 32-bit Windows, the server VM
>> will automatically be selected on server-class machines. The definition of
>> a server-class machine may change from release to release, so please check
>> the appropriate ergonomics document for the definition for your release.
>> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
>> http://www.oracle.com/technetwork/java/ergo5-140223.html>.\u201d
>>
>> Hence Sokolenko's comment:
>>
>> \u201cThough this option is implicitely enabled for x64 virtual machines, it
>> still makes sense to use it as according to documentation behaviour
>> maybe changed in the future.\u201d
>>
>> So this is still true and I wonder if we should not add this option (and
>> some others, see Sokolenko's link above) in some ant targets like "start"
>>
>> Opinions?
>>
>> Jacques
>>
>>
Re: Java default options in ant targets
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
So it seems for Oracle's JVM the only place where this makes an impact is
in Windows 32 bit architectures.
I am not sure, but I think it would be better not to pass the flag. Why?
Because the documentation provided by Oracle states that if you omit
-server then the JVM will decide based on hardware spects, more
specificailly: "For Java SE 6, the definition of a *server-class* machine
is one with at least 2 CPUs and at least 2GB of physical memory. "
Reference below with grid.
http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
So if you omit the -server flag on an old piece of hardware, then it will
consider it a client. and the main difference between client and server has
to do with the JIT compiler and startup time vs memory management (server
has more over head but more optimization long term). It makes sense not to
consider old hardware as server to avoid the overhead.
The only exception, again, is windows 32. Again not sure but I suspect we
do not have a lot of new hardware Windows 32 servers running OFBiz, but I
could be wrong of course.
Regards,
Taher Alkhateeb
On Thu, Jun 9, 2016 at 8:28 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi,
>
> I was reading "Java Concurrency in Practice" (again!) when I (again!)
> stumbled upon the 6th footnote p. 38 (my edition is from 2011)
>
> You can find a summary at
> https://www.goodreads.com/work/quotes/123207-java-concurrency-in-practice
> :
>
> “Debugging tip: For server applications, be sure to always specify the
> -server JVM command line switch when invoking the JVM, even for
> development and testing. The server JVM performs more optimization than
> the client JVM, such as hoisting variables out of a loop that are not
> modified in the loop; code that might appear to work in the development
> environment (client JVM) can break in the deployment environment (server
> JVM)...(more explanation and examples)”
>
> Since this book was written in 2006 for Java 5, I checked what the
> situation is with Java 8
>
> http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#compiler_types
>
> http://blog.sokolenko.me/2014/11/javavm-options-production.html#make-server-a-server
>
> Oracle says
>
> “Since Java SE 5.0, with the exception of 32-bit Windows, the server VM
> will automatically be selected on server-class machines. The definition of
> a server-class machine may change from release to release, so please check
> the appropriate ergonomics document for the definition for your release.
> For 5.0, it'sErgonomics in the 5.0 Java[tm] Virtual Machine <
> http://www.oracle.com/technetwork/java/ergo5-140223.html>.”
>
> Hence Sokolenko's comment:
>
> “Though this option is implicitely enabled for x64 virtual machines, it
> still makes sense to use it as according to documentation behaviour
> maybe changed in the future.”
>
> So this is still true and I wonder if we should not add this option (and
> some others, see Sokolenko's link above) in some ant targets like "start"
>
> Opinions?
>
> Jacques
>
>