Re: Question about BUILD_HEADLESS and HEADLESS
On 14/02/2012 11:47 PM, Fredrik Öhrström wrote: Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological remnant and should be removed? (No source in the hotspot repo looks a the HEADLESS define.) I agree this seems superfluous. There's no use of the HEADLESS define in the Hotspot sources. Is there any reason to not build a headless version of awt? (ie modify BUILD_HEADLESS to not be defined.) It seeems like headless is not currently built on bsd/macosx/windows, but it is built on solaris and linux? I'm not sure what you are asking. BUILD_HEADLESS is a JDK build flag. As you say it is set true in the linux and solaris Def-.gmk files, and AFAICS it is only used in one place in make/sun/headless/Makefile Note: BUILD_HEADLESS_ONLY is an unrelated option that was added to support special SE Embedded builds on platforms with no X11 includes or libraries available at all. David - //Fredrik
Re: building part of jdk 8
I don't know if this is a problem but it's something I noticed. When I do the full fastdebug_build build there are two directories under C:\OpenJDK\jdk8\build\windows-i586-fastdebug\tmp\sun\sun.awt\awt, i.e. CClassHeaders and Obj_gO. When I then do the partial build of awt (described in the history below) a new directory, obj, is added and populated. On 2/13/12 3:13 PM, Kelly O'Hair wrote: > On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote: > >> On 2/13/12 1:35 PM, Kelly O'Hair wrote: >>> Just a few comments below... >>> >>> On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote: >>> This worked for me today for building just awt: This is in my bat file. The first two sets are what resolved my issue. set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image >>> The above two settings make no sense to me. >>> >>> ALT_OUTPUTDIR is supposed to point at the directory where you want the >>> build results to go. >>> One of the directories created is the j2sdk-image. This is a huge disk >>> write area. >> I think I needed this to make my partial build use the same directory as >> my fastdebug_build full build. > Understood. That's a perfectly valid reason. > >>> ALT_JDK_IMPORT_PATH is something you set when you are doing partial builds, >>> e.g. >>> not building hotspot. It needs to point at some place that is pretty golden >>> and steady, for >>> a place to get parts of the jdk image that you are not building. >>> You have it set to the same place you are building. :^( That seems fishy >>> to me. >>> I would have done a full build, moved or copied j2sdk-image to some place >>> safe, and >>> had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from >>> destruction >>> during the build. >> I only build parts of awt and swing so maybe I've been lucky. In any >> event I made that change. set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 >>> The official boot jdk for jdk8 is actually the first shipping jdk7, >>> although 7u2 should work, >>> our release engineering and automated build systems use jdk7 fcs. >>> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin >>> Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary for >>> some reason? >>> set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i >>> This bash command will add /usr/bin to the PATH, and convert PATH to the >>> CYGWIN world. >> Do I need to change something? > No you are perfectly fine. I was just commenting that the PATH setting has > changed. > I always keep track of when PATH changes. > Then at the cygwin command line: eval `bin/vsvars.sh -v10 -32` >>> Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio >>> compiler. >>> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 2>&1 | tee build.log >>> Yup. >>> Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. >>> I've never been sure about Wbem needing to be in the system path. Let me >>> know what you find out. >> Rebuilding after tweaking awt_Component.cpp worked fine without this. >> I'll report back at some other time after doing a full rebuild. > http://www.pcreview.co.uk/forums/do-need-wbem-path-statement-t2330116.html > > My tendency is to leave Wbem in PATH. Not sure we need it, but why vary the > standard Windows > PATH and ask for trouble? ;^) > > -kto > >>> >>> So this is Windows 7 right? >>> Is it Windows 7 X64 or X86? (32 or 64 bit OS) >> 64 bit Windows 7 >>> Do you have any anti-virus software installed, and any special settings? >> I have Norton 360 and for a full build I disable auto-protect. I don't >> bother disabling that for a partial build. >>> Is this the latest CYGWIN? (what does uname -a say?) >> 1.7.0 (I dropped back from using 1.7.9 and so far this has been working, >> but I haven't done enough full builds yet to be sure.) >> >> Pete >>> There have been reports of problems with Windows 7 building, possibly >>> involving CYGWIN and McAfee >>> colliding somehow. Just curious. >>> >>> -kto >>> Pete On 2/2/12 2:19 PM, Pete Brunet wrote: > On 2/1/12 10:54 PM, Pete Brunet wrote: >> On 1/23/12 9:39 AM, Pete Brunet wrote: >>> In the past I was able to build part of jdk 8 but that is not currently >>> working although I am able to do a full 32 bit build. I've recently >>> moved from XP to W7 so my environment might not be set up quite right >>> yet. Here's what I do... >>> >>> // These are done in a bat file before I do any makes >>> s
Re: Is anyone able to build on Win 7
Fantastic information set. Many thanks for all this digging.
I suspect, that our build infrastructure work may help, in that if we get rid
of the nested makes,
then I can only assume we will be doing fewer stat() calls, but I think we
still have a problem.
A year or so ago, I managed to reduce the fork/exec count by 50% thinking it
would improve windows
build times, it did very little, I was disappointed, and assumed the bigger
spike had to be related to I/O.
So I tried a fast SSD on a Windows machine, which sure made it quiet, but also
didn't help much.
So I'm with you on the stat() theory, makes a great deal of sense.
-kto
On Feb 14, 2012, at 6:59 AM, Volker Simonis wrote:
> On Tue, Feb 14, 2012 at 12:43 PM, Fredrik Öhrström
> wrote:
>> 2012-02-14 12:29, Volker Simonis skrev:
>>> To cut a long story short:
>>> - disabling "on access" scanning of *.{java,c,cpp,h,hpp} seems to
>>> resolve the file io problems (permission denied, access denied)
>>> - disabling ASLR seems to resolve the "fork" problems
>>
>> Great work! Do you know if disabling ASLR affects the fork performance
>> on 64 bit windows?
>>
>
> No, definitely not.
> The build time on my DualCore i7 @ 2.7 GHz notebook with 8GB Ram is
> constantly 1h43min for a full JDK8 opt build.
>
> Now that that the build seems stable I want to compare it with a Linux
> build in a VirtualBox VM on the same host.
> I'll let you know the results once I'm done, but I don't think that
> "fork" is the big problem - at least not the only one.
>
> But once you asked here's my main suspect since long time (you asked
> so you have to read the conspiracy:)
>
> stat (or lstat/fstat/stat64 ...)
> -
>
> I'm quite sure that the poor implementation of stat in Cygwin and its
> usage in make is one of the main reasons
> why the build Windows build is so terrible slow in Windows compared to Linux.
>
> I first realized this years ago when I was first building Windows
> inside a VMWare image with the sources on
> network shares. The build times were excessively long and it was not
> the compile times because SMB shares
> do a quite efficient caching - it was the times which make needed in
> order to check the build dependencies.
> The build times could be improved by factors if the sources were moved
> to a local disc.
>
> But even locallly, I think that the stat calls for large dependency
> lists as we have them in the OpenJDK build
> may still be one of the causes for the slow build. Running make inside
> strace will reveal the shear number
> of these calls and there is evidence that the stat performance is
> really poor in Cygwin.
>
> I'll attach some unsorted links to some of the resources which discuss
> this issue just in case somebody wants to
> deep dive into this topic. I'm definitely not a Windows/Cygwin expert
> and I can't promise I'll have the time
> to solve it 'real soon' but I'll definitely stick to this topic
> because it is a real PITA (especially if you want to
> change your build from MKS to Cygwin the developers who will first
> love you because freed them from of
> the MKS licensing night mare will very soon kill you because of the
> build times:)
>
> "performance issue with cgywin make"
> http://www.mail-archive.com/make-w32@gnu.org/msg01353.html
>
> - mailing list thread which compares the bad performance of Cygwin
> make with MS nmake and discusses
> how some of the problems have been solved in CMake by using direct
> windows sys-calls instead of stat.
>
> "make 3.82 performing more stat() calls than 3.81"
> http://lists.gnu.org/archive/html/bug-make/2011-09/msg00025.html
>
> - mailing list thread discussing a bug in make 3.82 which leads to
> even more calls to stat
> (and has been fixed already in the head revision of make)
>
>
> "Cygwin Performance and stat()"
> http://omgili.com/mailinglist/cygwin/cygwin/com/efe8a37b2e4466daa7b6eb1aa610c3d7squirrelebmailwingertorg.html
>
> - very long thrad, very ‘flamy’, no outcome, some interesting infos
> nevertheless
>
> "cygwin: Use native Win32 API for stat"
> http://marc.info/?l=git&m=122278284210941
>
> - partial patch for the problem by implementing a stripped down
> version of stat which does just enough...
>
> "_NutFastStat(), _NutFastStat64()"
> http://www.mkssoftware.com/docs/man3/_NutFastStat.3.asp
>
> - MKSs limited but faster version of stat (not sure if MKS make uses
> this, but that may be an
> explanation why builds under MKS are reported to be considerably
> faster compared to Cygwin builds
>
> "Managing Projects with GNU Make, 3rd Edition, The Power of GNU make
> for Building Anything, By Robert Mecklenburg"
> http://shop.oreilly.com/product/9780596006105.do
>
> - Chapter 10: "Improving the Performance of make" freely available as
> PDF download:
> http://reilly.com/catalog/make3/book/ch10.pdf
>
>
> "Compile time Local Cygwin vs. VMware session on same system"
> http://cygwin.com/ml/cygwin/2008-10/threads.html#00415
>
> - m
Re: Question about BUILD_HEADLESS and HEADLESS
On windows headless is simply a state. But Solaris/Linux have "true" headless builds where there are headless (stub) versions of UI libraries. And I think that headless is a valid JCK mode .. you can pass JCK in headless on platforms that don't support UI. But I'd check the JCK guys on that one, don't take my word for it. -phk. On 2/14/2012 6:49 AM, Michael McMahon wrote: On 14/02/12 13:47, Fredrik Öhrström wrote: Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological remnant and should be removed? (No source in the hotspot repo looks a the HEADLESS define.) Is there any reason to not build a headless version of awt? (ie modify BUILD_HEADLESS to not be defined.) It seeems like headless is not currently built on bsd/macosx/windows, but it is built on solaris and linux? //Fredrik Fredrik, It's being built on macosx as well. - Michael.
Re: Is anyone able to build on Win 7
On Tue, Feb 14, 2012 at 12:43 PM, Fredrik Öhrström
wrote:
> 2012-02-14 12:29, Volker Simonis skrev:
>> To cut a long story short:
>> - disabling "on access" scanning of *.{java,c,cpp,h,hpp} seems to
>> resolve the file io problems (permission denied, access denied)
>> - disabling ASLR seems to resolve the "fork" problems
>
> Great work! Do you know if disabling ASLR affects the fork performance
> on 64 bit windows?
>
No, definitely not.
The build time on my DualCore i7 @ 2.7 GHz notebook with 8GB Ram is
constantly 1h43min for a full JDK8 opt build.
Now that that the build seems stable I want to compare it with a Linux
build in a VirtualBox VM on the same host.
I'll let you know the results once I'm done, but I don't think that
"fork" is the big problem - at least not the only one.
But once you asked here's my main suspect since long time (you asked
so you have to read the conspiracy:)
stat (or lstat/fstat/stat64 ...)
-
I'm quite sure that the poor implementation of stat in Cygwin and its
usage in make is one of the main reasons
why the build Windows build is so terrible slow in Windows compared to Linux.
I first realized this years ago when I was first building Windows
inside a VMWare image with the sources on
network shares. The build times were excessively long and it was not
the compile times because SMB shares
do a quite efficient caching - it was the times which make needed in
order to check the build dependencies.
The build times could be improved by factors if the sources were moved
to a local disc.
But even locallly, I think that the stat calls for large dependency
lists as we have them in the OpenJDK build
may still be one of the causes for the slow build. Running make inside
strace will reveal the shear number
of these calls and there is evidence that the stat performance is
really poor in Cygwin.
I'll attach some unsorted links to some of the resources which discuss
this issue just in case somebody wants to
deep dive into this topic. I'm definitely not a Windows/Cygwin expert
and I can't promise I'll have the time
to solve it 'real soon' but I'll definitely stick to this topic
because it is a real PITA (especially if you want to
change your build from MKS to Cygwin the developers who will first
love you because freed them from of
the MKS licensing night mare will very soon kill you because of the
build times:)
"performance issue with cgywin make"
http://www.mail-archive.com/make-w32@gnu.org/msg01353.html
- mailing list thread which compares the bad performance of Cygwin
make with MS nmake and discusses
how some of the problems have been solved in CMake by using direct
windows sys-calls instead of stat.
"make 3.82 performing more stat() calls than 3.81"
http://lists.gnu.org/archive/html/bug-make/2011-09/msg00025.html
- mailing list thread discussing a bug in make 3.82 which leads to
even more calls to stat
(and has been fixed already in the head revision of make)
"Cygwin Performance and stat()"
http://omgili.com/mailinglist/cygwin/cygwin/com/efe8a37b2e4466daa7b6eb1aa610c3d7squirrelebmailwingertorg.html
- very long thrad, very ‘flamy’, no outcome, some interesting infos nevertheless
"cygwin: Use native Win32 API for stat"
http://marc.info/?l=git&m=122278284210941
- partial patch for the problem by implementing a stripped down
version of stat which does just enough...
"_NutFastStat(), _NutFastStat64()"
http://www.mkssoftware.com/docs/man3/_NutFastStat.3.asp
- MKSs limited but faster version of stat (not sure if MKS make uses
this, but that may be an
explanation why builds under MKS are reported to be considerably
faster compared to Cygwin builds
"Managing Projects with GNU Make, 3rd Edition, The Power of GNU make
for Building Anything, By Robert Mecklenburg"
http://shop.oreilly.com/product/9780596006105.do
- Chapter 10: "Improving the Performance of make" freely available as
PDF download:
http://reilly.com/catalog/make3/book/ch10.pdf
"Compile time Local Cygwin vs. VMware session on same system"
http://cygwin.com/ml/cygwin/2008-10/threads.html#00415
- mail thread suggesting the usage of ‘dash’ instead of ‘bash’ for a
>10% performance improvement
> //Fredrik
>
Re: Question about BUILD_HEADLESS and HEADLESS
On 14/02/12 13:47, Fredrik Öhrström wrote: Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological remnant and should be removed? (No source in the hotspot repo looks a the HEADLESS define.) Is there any reason to not build a headless version of awt? (ie modify BUILD_HEADLESS to not be defined.) It seeems like headless is not currently built on bsd/macosx/windows, but it is built on solaris and linux? //Fredrik Fredrik, It's being built on macosx as well. - Michael.
Question about BUILD_HEADLESS and HEADLESS
Is the use of HEADLESS in gcc.make (linux and bsd) an archaeological remnant and should be removed? (No source in the hotspot repo looks a the HEADLESS define.) Is there any reason to not build a headless version of awt? (ie modify BUILD_HEADLESS to not be defined.) It seeems like headless is not currently built on bsd/macosx/windows, but it is built on solaris and linux? //Fredrik
Re: Is anyone able to build on Win 7
2012-02-14 12:29, Volker Simonis skrev:
> To cut a long story short:
> - disabling "on access" scanning of *.{java,c,cpp,h,hpp} seems to
> resolve the file io problems (permission denied, access denied)
> - disabling ASLR seems to resolve the "fork" problems
Great work! Do you know if disabling ASLR affects the fork performance
on 64 bit windows?
//Fredrik
Re: Is anyone able to build on Win 7
Hi Kelly,
that's an interesting hint. I looked at it and tried to understand
what's behind it.
Here's what I found out - if I'm wrong or if somebody has additional
information I
would appreciate any correction!
1. Windows DLLs have a base address which indicates the virtual base address
where they would like to get loaded to.
2. If this address is already in use, the operating system chooses
another base address
and the DLL is relocated to that new base address.
Relocation should be no problem for a DLL, but apparently the
implementation of "fork()"
in Cygwin is very picky about these base addresses and "..needs to
have a very special
memory layout to implement the fork semantics in Win32. If this memory
layout is disrupted,
fork breaks.." (from http://www.cygwin.com/ml/cygwin/2009-05/msg00413.html).
3. The McAffe knowledge base entry cited by Kelly states: "..When a
Cygwin DLL fails to load
to the default address, Windows arbitrarily chooses an available
address and loads it there.
That works only as long as Windows chooses the same address every
time, but there are a
lot of conditions during startup that may affect the outcome."
4. Cygwin comes with its own rebase tool (/bin/rebaseall) which
"..does its best to locate all
Cygwin DLLs that it knows of into a layout that avoids collisions.."
"rebaseall" is usually called by setup.exe so if you do not manually
install any DLLs, this
shouldn't be a problem.
I indeed ran 'rebaseall' (call 'rebaseall --help' for an instruction
how to use it) without
any positive effect and I assume this is because all the DLLs already
had non-overlapping
base addresses. There's one thing to keep in mind however: Cygwins
'rebaseall' can not
rebase 'cygwin1.dll' because it is linked against it. To rebase
'cygwin1.dll' one has to use
another rebase tool (e.g. "C:\Program Files\Microsoft
SDKs\Windows\v7.1\Bin\ReBase.Exe"
from the MS SDK). I've done that but that even worsened things
(probably because it is not
so easy to rebase cygwin1.dll to a meaningful new base address without
knowing the
memory layout of 32-bit Windows processes:).
5. During all these experiments I ran across another new Windows7
feature called ASLR
(Address Space Layout Randomization, see
http://en.wikipedia.org/wiki/Address_space_layout_randomization).
Actually it is not really new in Windows 7 but from what I've read it
is implemented much more
aggressively in Windows 7. On Windows 7, ASLR can only be disabled by
using the
Enhanced Mitigation Experience Toolkit provided by Microsoft
(http://support.microsoft.com/kb/2458544),
(the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\MoveImages
registry setting has no effect in Windows 7)
6. The default setting for ASLR is still "application opt in" which
means that only applications
which want will be randomized. You can check this for example with the
Cygwins /usr/bin/peflags
tool. It will display something like "[-dynamicbase]" for applications
which don't want to be
randomized. Now all Cygwin DLL's have "-dynamicbase", so why should
this be a problem?
My naive explanation is that the Cygwin DLLs still depend an native
Windows runtime DLLs and
they all will be randomized by default. If now one of these Windows
sysytem DLLs will be placed
at the default base address of a Cygwin DLL, the Cygwin DLL will have
to be relocated with the
outcome described in 2.
7. I switched ASLR off (you need to reboot afterwards) and was able to
do 4 consecutive,
full builds without any error. After that I switched ASLR on again,
rebooted and the second
build failed with the well known "fork" problem.
To cut a long story short:
- disabling "on access" scanning of *.{java,c,cpp,h,hpp} seems to
resolve the file io problems (permission denied, access denied)
- disabling ASLR seems to resolve the "fork" problems
I would be graceful if anybody could confirm these findings or can
come up with another, better solution/explanation.
Regards,
Volker
On Thu, Feb 9, 2012 at 9:42 PM, Kelly O'Hair wrote:
>
> Does this article provide any help:
>
> https://kc.mcafee.com/corporate/index?page=content&id=KB55075&actp=search&viewlocale=en_US&searchid=1328818133782
>
> It suggests that rebase'ing the CYGWIN DLL's will help. Seems a bit strange
> to me, just passing it on.
>
> -kto
>
> On Jan 25, 2012, at 5:10 PM, Pete Brunet wrote:
>
>> I just had success with the following changes:
>> - downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash
>> 3.2.49)
>> - changed ...\jdk\make\docs\Makefile line 74
>>
>> ifeq ($(ARCH_DATA_MODEL),64)
>> MAX_VM_MEMORY = 1024
>> else
>> MAX_VM_MEMORY = 1024 <--- This was 512
>> endif
>>
>> I've only done one build and in prior builds had other issues besides
>> the memory problem, i.e. fork and error 126, but there's always hope.
>>
>> If others could report their W7 configurations and whether or not there
>> were problems, that would be helpful.
>>
>> Pete
>>
>> On 1/25/12 6:17 PM, Kelly O'Hair wrote:
>>> Sorry gu
