Hi loi, I tried what you suggested and got the following.  What other
steps do I need to take?  -Pete

Setting environment for using Microsoft Visual Studio 2010 x86 tools.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>cd
c:\Users\Pete\JDK8\jdk8\hotspot\make\windows

c:\Users\Pete\JDK8\jdk8\hotspot\make\windows>PATH
%PATH%;c:\Users\Pete\cygwin-1.7.21\bin

c:\Users\Pete\JDK8\jdk8\hotspot\make\windows>create
c:\re\jdk8-b102\windows-i586

cygwin warning:
  MS-DOS style path detected:
c:\Users\Pete\JDK8\jdk8\hotspot\/make/windows/get_msc_ver.sh
  Preferred POSIX equivalent is:
/cygdrive/c/Users/Pete/JDK8/jdk8/hotspot/make/windows/get_msc_ver.sh
  CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
**************************************************************
Will generate VC10 {Visual Studio 2010}
c:\Users\Pete\JDK8\jdk8\hotspot\build\vs-i486\jvm.vcxproj
**************************************************************
Error: directory pointed to by c:\re\jdk8-b102\windows-i586
does not exist, or the variable is not set.

Usage: create HotSpotJDKDist

This is the VS build setup script (as opposed to the batch
build execution script). It creates a build directory if necessary,
copies the appropriate files out of the workspace into it, and
builds and runs ProjectCreator in it. This has the side-effect of creating
the c:\Users\Pete\JDK8\jdk8\hotspot\build\vs-i486\jvm.vcxproj file in
the build
space, which is then used in Visual C++.

The HotSpotJDKDist defines the JDK that should be used when running the JVM.
Environment variable FORCE_MSC_VER allows to override MSVC version
autodetection
.

NOTE that it is now NOT safe to modify any of the files in the build
space, since they may be overwritten whenever this script is run or
nmake is run in that directory.

c:\Users\Pete\JDK8\jdk8\hotspot\make\windows>md c:\re\jdk8-b102\windows-i586

c:\Users\Pete\JDK8\jdk8\hotspot\make\windows>create
c:\re\jdk8-b102\windows-i586

cygwin warning:
  MS-DOS style path detected:
c:\Users\Pete\JDK8\jdk8\hotspot\/make/windows/get_
msc_ver.sh
  Preferred POSIX equivalent is:
/cygdrive/c/Users/Pete/JDK8/jdk8/hotspot/make/w
indows/get_msc_ver.sh
  CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
**************************************************************
Will generate VC10 {Visual Studio 2010}
c:\Users\Pete\JDK8\jdk8\hotspot\build\vs-i486\jvm.vcxproj
**************************************************************
Warning: please set variable HOTSPOTMKSHOME to place where
         your MKS/Cygwin installation is

The system cannot find the batch label specified - usage

On 8/28/13 9:32 PM, Ioi Lam wrote:
> Pete,
>
> By the way, for the purposes of testing your build speed, instead of
> spending a long time building JDK8, maybe you can just build hotspot.
> It's not completely proportional but would give you some ideas whether
> you should consider getting another laptop :-)
>
> Start Menu -> All Programs -> Microsoft Visual Studio 2010 -> Visual
> Studio Tools -> Visual Studio Command Prompt (2010).
>
> This will open a DOS window with the x86 version of the VS2010
> tool-chain selected.
>
>    cd hotspot\make\windows
>    PATH %PATH%;c:\cygwin\bin
>    create d:\re\jdk8-b102\windows-i586
>
> When it's done, open the project file
> hotspot\build\vs-i486\jvm.vcxproj in VS2010 IDE.
>
> Tools -> Options -> Project and Solutions -> VC++ Project Settings ->
> Build Timing-> Yes
>
> Choose the"compiler1_debug" + "Win32" build combination
>
>     Build the solution
>     Clean the solution
>     Build the solutionfor the second time
>
> If you have 8GB RAM, the second build should have all the files
> cached, so you should have very little disk reads. It will still have
> writes because you're creating the obj files.
>
> On my laptop, even before the SSD swap, the second build time is below
> 1 minute, and you can see CPU utilization constantly at 100% (all 4
> "CPUs" in Windows  Task Manager are at 100%).
>
> Switching to an SSD actually doesn't help with this scenario (becuase
> it is CPU bound), but it does make the system 100 times more
> responsive. Switching between apps is instantaneous. I can opening up
> a few copies of different versions of Visual Studio IDE and they come
> up just in a few seconds. With the HDD it would take ages.
>
> Good luck!
>
> - Ioi
>
>
>
>
>
> On 08/28/2013 07:14 PM, Ioi Lam wrote:
>> On 08/28/2013 11:47 AM, Pete Brunet wrote:
>>> Thanks Tim,
>>>
>>> On 8/27/13 6:44 PM, Tim Bell wrote:
>>>> Good advice on the virus scanning front, and of course every bit
>>>> helps.
>>>>
>>>> Also keep in mind that laptop components often sacrifice performance
>>>> in favor of saving space, power, and battery life.  A laptop is not a
>>>> workstation.
>>>>
>>>> If your laptop drive is a sad little unit like mine, you pay and pay.
>>>> I use my laptop as a gateway to get access to more powerful hardware.
>>>>
>>>> Not sure what version of Windows you have, but as a quick measure you
>>>> could try running WinSAT if you have it, like this:
>>>>
>>>>
>>>>     C:/Windows/System32/WinSAT.exe disk
>>> Since winset ran in a separate window and it closed before I could use
>>> the info I needed this advice:
>>> http://superuser.com/questions/93826/winsat-command-line-closes-too-fast
>>>
>>> Running as admin solved it.
>>>>
>>>> I'm sure your mileage will vary, but on my laptop I measured numbers
>>>> like:
>>>>
>>>>    56.536 ms for "Average Read Time with Sequential Writes"
>>>>    15.061 ms for "Average Read Time with Random Writes"
>>>> 153.103 ms for "Latency: 95th Percentile"
>>> Here are my numbers: 23.629, 30.545, 113.723 which are about 10x worse
>>> than your numbers below.  It would be interesting to see someone's
>>> numbers for a laptop SSD.
>>
>> Here are my numbers on a standard issue Dell laptop (Win7, i5-2520M
>> 2.5Ghz, 8GB RAM). I can't tell the model number since I am using
>> remote log-on now.
>>
>> I had swapped out the standard HDD with a Samsung 840 PRO SSD 256GB
>> (MZ-7PD256BW). It cost about $230 on amazon and is rated as "best" by
>> some web site I last checked :-)
>>
>> > Disk  Sequential 64.0 Read                   530.91 MB/s         7.9
>> > Disk  Random 16.0 Read                       449.02 MB/s         7.9
>> > Responsiveness: Average IO Rate              0.21 ms/IO          7.9
>> > Responsiveness: Grouped IOs                  6.77 units          7.7
>> > Responsiveness: Long IOs                     0.45 units          7.9
>> > Responsiveness: Overall                      3.02 units          7.9
>> > Responsiveness: PenaltyFactor                0.0
>> > Disk  Sequential 64.0 Write                  471.76 MB/s         7.9
>> > Average Read Time with Sequential Writes     0.270 ms            7.9
>> > Latency: 95th Percentile                     1.463 ms            7.9
>> > Latency: Maximum                             5.702 ms            7.9
>> > Average Read Time with Random Writes         0.267 ms            7.9
>> > Total Run Time 00:01:05.79
>>
>> I'll pull the latest jdk8 and post my build times.
>>
>> Ioi
>>
>>>> Whereas on a VM located somewhere out in a datacenter I have never
>>>> seen, I measured:
>>>>
>>>>    2.573 ms for "Average Read Time with Sequential Writes"
>>>>    3.574 ms for "Average Read Time with Random Writes "
>>>> 13.008 ms for "Latency: 95th Percentile"
>>>>
>>>> In both cases I was running Windows 7 64-bit.  Virus scanning and
>>>> other S/W are installed as per corporate policy.  Also, I am only
>>>> picking on the VM because it was convenient.  Try the same tests on
>>>> some bare metal workstation hardware if you have a chance.
>>> What do I need to do to use a datacenter VM?  Would the latency from
>>> Austin negate the gain in disk performance?
>>>> Hope this helps.
>>>>
>>>> Tim
>>>>
>>>> On 08/27/13 03:51 PM, Kelly O'Hair wrote:
>>>>> Peter,
>>>>>
>>>>> It might be important for you to make sure the boot jdk image, and
>>>>> all tools used to build (like VS2010) also in the ignore list. Maybe
>>>>> CYGWIN too.
>>>>> The boot jdk rt.jar file in particular can be slow to virus scan.
>>>>> It kind of depends on how smart (or not) the virus scanner is on
>>>>> re-scanning already scanned files.
>>>>>
>>>>> -kto
>>>>>
>>>>> On Aug 27, 2013, at 2:14 PM, Pete Brunet wrote:
>>>>>
>>>>>> Here are my release build times with my repo tree in the Norton 360
>>>>>> real
>>>>>> time virus checking ignore list:
>>>>>>
>>>>>> 00:03:34 corba
>>>>>> 00:12:51 demos
>>>>>> 00:15:10 docs
>>>>>> 00:18:42 hotspot
>>>>>> 00:15:55 images
>>>>>> 00:01:42 jaxp
>>>>>> 00:07:32 jaxws
>>>>>> 00:43:04 jdk
>>>>>> 00:04:17 langtools
>>>>>> 00:02:31 nashorn
>>>>>> 02:05:18 TOTAL
>>>>>>
>>>>>> Here are the prior times:
>>>>>>
>>>>>> 00:05:55 corba
>>>>>> 00:09:46 demos
>>>>>> 00:15:00 docs
>>>>>> 00:18:37 hotspot
>>>>>> 00:17:13 images
>>>>>> 00:03:32 jaxp
>>>>>> 00:11:41 jaxws
>>>>>> 01:05:35 jdk
>>>>>> 00:06:47 langtools
>>>>>> 00:02:26 nashorn
>>>>>> 02:37:45 TOTAL
>>>>>>
>>>>>> A half hour improvement is nice, but looks like I need to switch to
>>>>>> an SSD.
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>> On 8/9/13 11:25 AM, Pete Brunet wrote:
>>>>>>> Any suggestions for SSDs?  My T500 takes 2.5" SATA II.
>>>>>>>
>>>>>>> On 8/9/13 10:44 AM, Andreas Rieber wrote:
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> try perfmon.exe to see where the bottleneck is. Most likely it is
>>>>>>>> memory or io. If you have the option, go for a SSD drive (you will
>>>>>>>> get
>>>>>>>> build times ~10 minutes).
>>>>>>>>
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09.08.13 16:44, Pete Brunet wrote:
>>>>>>>>> My product is Norton 360.  To turn it off I right click on the
>>>>>>>>> Norton
>>>>>>>>> 360 icon in the system tray and choose Disable Antivirus
>>>>>>>>> Auto-Protect.
>>>>>>>>> If anyone knows if this is not sufficient and what else needs to
>>>>>>>>> be done
>>>>>>>>> please let me know.
>>>>>>>>>
>>>>>>>>> Pete
>>>>>>>>>
>>>>>>>>> On 8/9/13 1:58 AM, Erik Joelsson wrote:
>>>>>>>>>> I wonder if anti virus is really turned off here. In my
>>>>>>>>>> experience,
>>>>>>>>>> it's hard to make it stop completely. I have a slightly older
>>>>>>>>>> laptop,
>>>>>>>>>> same brand, that builds this in around 40-45 minutes.
>>>>>>>>>>
>>>>>>>>>> /Erik
>>>>>>>>>>
>>>>>>>>>> On 2013-08-09 03:32, Pete Brunet wrote:
>>>>>>>>>>> Haven't rebuilt a release version yet for a true comparison but
>>>>>>>>>>> here are
>>>>>>>>>>> my fastdebug times with anti-virus turned off; about the
>>>>>>>>>>> same as
>>>>>>>>>>> release
>>>>>>>>>>> with anti-virus on.
>>>>>>>>>>>
>>>>>>>>>>> 00:04:30 corba
>>>>>>>>>>> 00:07:25 demos
>>>>>>>>>>> 00:16:28 docs
>>>>>>>>>>> 00:16:15 hotspot
>>>>>>>>>>> 00:23:13 images
>>>>>>>>>>> 00:04:18 jaxp
>>>>>>>>>>> 00:07:29 jaxws
>>>>>>>>>>> 00:59:41 jdk
>>>>>>>>>>> 00:05:11 langtools
>>>>>>>>>>> 00:01:42 nashorn
>>>>>>>>>>> 02:26:32 TOTAL
>>>>>>>>>>>
>>>>>>>>>>> Pete
>>>>>>>>>>>
>>>>>>>>>>> On 8/6/13 12:55 PM, Kelly O'Hair wrote:
>>>>>>>>>>>> 4. Using a debug jdk as your boot jdk
>>>>>>>>>>>>
>>>>>>>>>>>> :)
>>>>>>>>>>>>
>>>>>>>>>>>> Langtools taking 6 minutes is crazy long. Since there is no
>>>>>>>>>>>> native
>>>>>>>>>>>> code there, #1 would be my first guess.
>>>>>>>>>>>>
>>>>>>>>>>>> -kto
>>>>>>>>>>>>
>>>>>>>>>>>> On Aug 5, 2013, at 5:54 PM, Weijun Wang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>    From my experiences there are 3 reasons a compile could be
>>>>>>>>>>>>> slow:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Anti-Virus programs
>>>>>>>>>>>>> 2. Virtual Machines
>>>>>>>>>>>>> 3. Network folders
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Max
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/6/13 12:48 AM, Pete Brunet wrote:
>>>>>>>>>>>>>> Hi Erik,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 00:05:55 corba
>>>>>>>>>>>>>> 00:09:46 demos
>>>>>>>>>>>>>> 00:15:00 docs
>>>>>>>>>>>>>> 00:18:37 hotspot
>>>>>>>>>>>>>> 00:17:13 images
>>>>>>>>>>>>>> 00:03:32 jaxp
>>>>>>>>>>>>>> 00:11:41 jaxws
>>>>>>>>>>>>>> 01:05:35 jdk
>>>>>>>>>>>>>> 00:06:47 langtools
>>>>>>>>>>>>>> 00:02:26 nashorn
>>>>>>>>>>>>>> 02:37:45 TOTAL
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pete
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/5/13 6:55 AM, Erik Joelsson wrote:
>>>>>>>>>>>>>>> That was disappointingly slow for sure. Do you have the
>>>>>>>>>>>>>>> build time
>>>>>>>>>>>>>>> summary listing?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Erik
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2013-08-02 22:26, Pete Brunet wrote:
>>>>>>>>>>>>>>>> FWIW I just built 32 bit jdk8 release on 64 bit win 7 with
>>>>>>>>>>>>>>>> cygwin 1.7.21
>>>>>>>>>>>>>>>> on a dual core 8 GB 2.53 GHz Lenovo T500 and the build
>>>>>>>>>>>>>>>> time was
>>>>>>>>>>>>>>>> 2:37:45.
>>
>

Reply via email to