dev@glassfish.java.net

Re: Changes to VM tuning.

From: charlie hunt <charlie.hunt_at_sun.com>
Date: Sun, 22 Jul 2007 13:50:58 -0500

Just because GlassFish is a server, doesn't mean that it's advantageous
to *always* be started & run with -server.

Consider the developer use of; code an Java EE app, start GlassFish,
deploy it to GlassFish and validate the deployed app. GlassFish
launched with -client will launch faster and likely have a smaller
footprint too. Deploy time may also be less in this use case. For
production systems, yes -server JVM is what should be used.

Further consider a developer evaluating GlassFish, he or she's gonna
write a simple, start GlassFish, deploy the app, look at via a browser.
That developer may do that with several additional sample or example
applications.

 From my experience working with the NetBeans team, developer adoption
is all about developer productivity. If one can improve the most common
developer use case(s), you'll improve that developer's productivity run
a much higher probability of gaining developer adoption.

What's your reaction gonna be if you observe GlassFish startup time
taking up to 30% longer? Fwiw, several years ago when I last compared
-server to -client it was on the order of 30%. What if the startup
time of GlassFish with -client is comparable to Tomcat startup time and
GlassFish with -server is 30% slower?

The good news is ... in the JDK 7 time frame you may see tiered
compilation which should give you nearly the same short term startup and
deployment speed benefits, but also give you the long term speed
benefits of running -server.

Btw, since Apple ports HotSpot, we (HotSpot engineering) have no control
over whether they decide to use the ergonomics built-in to deciding
whether to user a -server JVM or -client JVM. It appears they are
utilizing the same logic as seen by HotSpot when HotSpot sees a Windows
platform.

charlie ...

Lloyd L Chambers wrote:
> But GlassFish is a server. Why wouldn't ALL invocations of the JVM
> that start GlassFish be marked as "server"? After all, it's our
> script that controls the JVM options, right?
>
> On Jul 20, 2007, at 1:56 PM, Scott Oaks wrote:
>
>> On Fri, 2007-07-20 at 16:47, Lloyd L Chambers wrote:
>>> What's a "server class machine"? How/when are the two distinguished?
>>
>> http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html
>>>
>>> For example, is a 3GHz quad-core Mac OS X box a "client class"
>>> machine and a Solaris 1.4 GHz dual-core machine "server class"? What
>>> is the logic (or lack of it)?
>>
>> You'll have to ask the JVM team for a full answer, but it's really the
>> thought that for 99% of the people on Windows and Macs, Java runs
>> primarly for their browsers, and the client JVM has many advantages
>> there (regardless of the cores or CPU speed they have).
>>
>> -Scott
>>
>>>
>>> On Jul 20, 2007, at 1:37 AM, Binod wrote:
>>>
>>>>
>>>> Hi everyone,
>>>>
>>>> Heads up regarding some changes to default JVM options for glassfish.
>>>> I am planning to do the check-in in next couple of days.
>>>>
>>>> We are removing the default -client option from the developer profile
>>>> domain.xml. That means that in server class machines glassfish
>>>> will be
>>>> starting with -server VM (tuned for runtime performance and not
>>>> startup).
>>>>
>>>> When VM is server, QuickStartup also will be switched off as the
>>>> intention is to tune for runtime performance in server-class machines
>>>> and not startup.
>>>>
>>>> In client-class machines the current behaviour will continue as the
>>>> JDK
>>>> will pick -client as the default VM.
>>>>
>>>> thanks,
>>>> Binod.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>


-- 
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>