Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Jonathan Gibbons 

Kelly O'Hair wrote:





I also like the approach I advocated some years ago:
- run tests under JDK 1
- run tests under JDK 2
- diff the results (JTreport directories)
See my diff-javatest script.
jtreg now has support for this (I haven't tried it lately).


In an ideal world, one set of results would be the set of results posted 
publicly somewhere for the latest promoted build.  But we don't seem to 
be able to make that happen, so I agree with Kelly that for now we need 
a more pragmatic approach of defining the set of tests we expect to work 
on every platform on every build.  Hopefully, over time, the relevant 
engineers will aspire to have their tests included in this set of tests.



-- Jon

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Kelly O'Hair 



Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :


Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :

Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :

I'm basically ok with this, but have one concern.

There is no longer a default ant value for drops.dir, it is only
set via the Makefile. Maybe that's ok, just not sure.
I think it means that a plain 'ant' command will always download
from the url. Again, maybe that's fine. So I'm ok with the push.


Ah I see what you mean.  I changed things so all the logic was in one
place in the Makefile:

ifdef ALT_DROPS_DIR
 DROPS_DIR = $(ALT_DROPS_DIR)
else
 ifdef ALT_JDK_DEVTOOLS_DIR
 DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
 else
 DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
 endif
endif

so you get the same behaviour as before, but as you say, only when
running ant via the makefile.
Is ant ever run directly in this situation? I've never had reason to do
so.

I do manually, and if you build via the NetBeans project. But the url
usage should work.


Either way, I can add an updated version back to the build.xml.
That's not a problem, as we'll never use it.

Can you allocate a bug ID so I can push? :)

6898251: Add ALT_DROPS_DIR feature to jaxp/jaxws


-kto


I've learned to keep ant scripts out of the environment variable
business if at all possible, so leaving any env var logic in
the makefiles may be fine.

Keeping the ant<->make boundaries simple seems like an essential
thing to do, sigh, but is anything "simple" with ant scripts or
Makefiles... :^(


I know what you mean all too well... :(
At one point, I managed to have three different JDKs, all from
different vendors, involved in the building of langtools...


-kto


Andrew John Hughes wrote:

2009/10/28 Andrew John Hughes :

snip..


Well spotted; revised version here:

http://cr.openjdk.java.net/~andrew/drops/webrev.03/

Does this look ok to push?

Thanks,

You've probably mentioned this before, but to which tree? I have it
applied to tl here for some reason I can't now remember...

You will need to use the jdk7/tl forest.

The jdk7/build forest doesn't have the jdk7/tl jaxp/jaxws changes yet.

-kto



Thanks all.

Pushed:

http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/26b97fd0e595
http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/600bc3d048be


Did you plan on doing this to jdk6 too?

-kto

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 


Martin Buchholz wrote:

On Wed, Nov 4, 2009 at 09:19, Kelly O'Hair  wrote:


Managing the ProblemList (as Jon noted) will be a pain at times.


It's even more of a problem as development becomes more distributed,
as failures become platform-dependent, etc...

I would prefer to see per-file annotations that jtreg can understand.


Not sure how annotating tests is any better in a distributed world,
or if tests failed in a platform-dependent way. Both seem nasty.

I have no objection and would actually prefer to see the testcases
annotated, with @ignore or whatever keywords people want to invent.
But I came to the conclusion that in general, relying on that as the sole
way to exclude unstable tests was just not good enough, and may not happen
for a long long time.
I would hope that eventually, this ProblemList shrinks, perhaps to
nothingness someday, I know I know,  ... dream on. :^(

The issue I saw was that regressions could sneak in all kinds of ways,
and at any given point in time, a testcase could become unstable
due to an OS patch, or a hotspot change, or something outside of the
jdk repository.

So we need a quick and easy way to exclude, and stop having dozens
of developers investigate the same known failures.
Yes, in many cases bugs should be filed, jdk bugs or testcase bugs,
but my first priority was to find that list of tests that pass reliably,
and stick my wizard's staff in the ground and say 'Thou shall pass!'. ;^)

Then see if we could start requiring a set of tests to always pass.

Next, I start going through the ProblemList in detail, with various
team help if possible, and see if we can shrink this problem down.



I also like the approach I advocated some years ago:
- run tests under JDK 1
- run tests under JDK 2
- diff the results (JTreport directories)
See my diff-javatest script.
jtreg now has support for this (I haven't tried it lately).


So you want everyone to run the tests twice?
Why run 6,000+ tests when you could run 3,000+ tests?

Now running all the ProblemList tests this way might be interesting,
if some of them didn't crash jtreg. :^(

-kto



Martin

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Andrew John Hughes 
2009/11/4 Kelly O'Hair :
>
>
> Andrew John Hughes wrote:
>>
>> 2009/11/4 Kelly O'Hair :
>>>
>>> Andrew John Hughes wrote:

 2009/11/4 Kelly O'Hair :
>
> I'm basically ok with this, but have one concern.
>
> There is no longer a default ant value for drops.dir, it is only
> set via the Makefile. Maybe that's ok, just not sure.
> I think it means that a plain 'ant' command will always download
> from the url. Again, maybe that's fine. So I'm ok with the push.
>
 Ah I see what you mean.  I changed things so all the logic was in one
 place in the Makefile:

 ifdef ALT_DROPS_DIR
  DROPS_DIR = $(ALT_DROPS_DIR)
 else
  ifdef ALT_JDK_DEVTOOLS_DIR
  DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
  else
  DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
  endif
 endif

 so you get the same behaviour as before, but as you say, only when
 running ant via the makefile.
 Is ant ever run directly in this situation? I've never had reason to do
 so.
>>>
>>> I do manually, and if you build via the NetBeans project. But the url
>>> usage should work.
>>>
 Either way, I can add an updated version back to the build.xml.
 That's not a problem, as we'll never use it.

 Can you allocate a bug ID so I can push? :)
>>>
>>> 6898251: Add ALT_DROPS_DIR feature to jaxp/jaxws
>>>
>>>
>>> -kto
>>>
> I've learned to keep ant scripts out of the environment variable
> business if at all possible, so leaving any env var logic in
> the makefiles may be fine.
>
> Keeping the ant<->make boundaries simple seems like an essential
> thing to do, sigh, but is anything "simple" with ant scripts or
> Makefiles... :^(
>
 I know what you mean all too well... :(
 At one point, I managed to have three different JDKs, all from
 different vendors, involved in the building of langtools...

> -kto
>
>
> Andrew John Hughes wrote:
>>
>> 2009/10/28 Andrew John Hughes :
>>
>> snip..
>>
>>> Well spotted; revised version here:
>>>
>>> http://cr.openjdk.java.net/~andrew/drops/webrev.03/
>>
>> Does this look ok to push?

 Thanks,
>>
>> You've probably mentioned this before, but to which tree? I have it
>> applied to tl here for some reason I can't now remember...
>
> You will need to use the jdk7/tl forest.
>
> The jdk7/build forest doesn't have the jdk7/tl jaxp/jaxws changes yet.
>
> -kto
>

Thanks all.

Pushed:

http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/26b97fd0e595
http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/600bc3d048be
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Martin Buchholz 
On Wed, Nov 4, 2009 at 09:19, Kelly O'Hair  wrote:

> Managing the ProblemList (as Jon noted) will be a pain at times.

It's even more of a problem as development becomes more distributed,
as failures become platform-dependent, etc...

I would prefer to see per-file annotations that jtreg can understand.

I also like the approach I advocated some years ago:
- run tests under JDK 1
- run tests under JDK 2
- diff the results (JTreport directories)
See my diff-javatest script.
jtreg now has support for this (I haven't tried it lately).

Martin

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Kelly O'Hair 



Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :


Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :

I'm basically ok with this, but have one concern.

There is no longer a default ant value for drops.dir, it is only
set via the Makefile. Maybe that's ok, just not sure.
I think it means that a plain 'ant' command will always download
from the url. Again, maybe that's fine. So I'm ok with the push.


Ah I see what you mean.  I changed things so all the logic was in one
place in the Makefile:

ifdef ALT_DROPS_DIR
 DROPS_DIR = $(ALT_DROPS_DIR)
else
 ifdef ALT_JDK_DEVTOOLS_DIR
  DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
 else
  DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
 endif
endif

so you get the same behaviour as before, but as you say, only when
running ant via the makefile.
Is ant ever run directly in this situation? I've never had reason to do
so.

I do manually, and if you build via the NetBeans project. But the url
usage should work.


Either way, I can add an updated version back to the build.xml.
That's not a problem, as we'll never use it.

Can you allocate a bug ID so I can push? :)

6898251: Add ALT_DROPS_DIR feature to jaxp/jaxws


-kto


I've learned to keep ant scripts out of the environment variable
business if at all possible, so leaving any env var logic in
the makefiles may be fine.

Keeping the ant<->make boundaries simple seems like an essential
thing to do, sigh, but is anything "simple" with ant scripts or
Makefiles... :^(


I know what you mean all too well... :(
At one point, I managed to have three different JDKs, all from
different vendors, involved in the building of langtools...


-kto


Andrew John Hughes wrote:

2009/10/28 Andrew John Hughes :

snip..


Well spotted; revised version here:

http://cr.openjdk.java.net/~andrew/drops/webrev.03/

Does this look ok to push?

Thanks,


You've probably mentioned this before, but to which tree? I have it
applied to tl here for some reason I can't now remember...


You will need to use the jdk7/tl forest.

The jdk7/build forest doesn't have the jdk7/tl jaxp/jaxws changes yet.

-kto

building OpenJDK on Mac OS X 1.5.8?

2009-11-04 Thread Ray Kiddy 


Hey -

A bit new to this project. Not sure what the procedure is here. I  
found this doc to work from and it got me pretty far:



http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5

But then after quite a while building, I get the following. Yet, as  
you can see, javah does exist, though perhaps not in the right place


I have a pretty standard dev setup. I removed X11, but that should not  
matter, yes? I work on WebObjects and Project Wonder with java and I  
build Firefox with some scripts and run mochitests and reftests. And  
stuff.


Any suggestions?

Full build log is at www.wykiwyk.com/openjdk/log004.txt. Except is  
below.


cheers - ray


Wed Nov  4 14:16:43 PST 2009
Control bsd i586 1.7.0-internal all build started:
( cd  ./jdk/make && \
  make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/Users/ 
ray/Projects/OpenJDK/bsd-port/jdk JDK_MAKE_SHARED_DIR=/Users/ray/ 
Projects/OpenJDK/bsd-port/jdk/make/common/shared
 EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7  
TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00  
JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-ray_2009_11_04_14_
16-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7  
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0  
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0  
ANT_HOME="/usr/share/ant" ALT_OUTPUTDIR=/Users/ray/Projects/OpenJDK/ 
bsd-port/build/bsd-i586 ALT_LANGTOOLS_DIST=/U
sers/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/langtools/dist  
ALT_CORBA_DIST=/Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/ 
corba/dist ALT_JAXP_DIST=/Users/ray/Projects/Ope
nJDK/bsd-port/build/bsd-i586/jaxp/dist ALT_JAXWS_DIST=/Users/ray/ 
Projects/OpenJDK/bsd-port/build/bsd-i586/jaxws/dist  
ALT_HOTSPOT_IMPORT_PATH=/Users/ray/Projects/OpenJDK/bsd-port/bu

ild/bsd-i586/hotspot/import BUILD_HOTSPOT=true ; )

Build Machine Information:
   build machine = arist.local

Build Directory Structure:
   CWD = /Users/ray/Projects/OpenJDK/bsd-port
   TOPDIR = .
   CONTROL_TOPDIR = .
   LANGTOOLS_TOPDIR = ./langtools
   JAXP_TOPDIR = ./jaxp
   JAXWS_TOPDIR = ./jaxws
   CORBA_TOPDIR = ./corba
   HOTSPOT_TOPDIR = ./hotspot
   JDK_TOPDIR = ./jdk

Build Directives:
   BUILD_LANGTOOLS = true
   BUILD_JAXP = true
   BUILD_JAXWS = true
   BUILD_CORBA = true
   BUILD_HOTSPOT = true
   BUILD_JDK= true
   DEBUG_CLASSFILES =
   DEBUG_BINARIES =

Hotspot Settings: \n  HOTSPOT_BUILD_JOBS  = 1 \n   
HOTSPOT_OUTPUTDIR   = /Users/ray/Projects/OpenJDK/bsd-port/build/bsd- 
i586/hotspot/outputdir \n  HOTSPOT_EXPORT_PATH =

/Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/hotspot/import \n \n

... and so on 

# Running javac:
/usr/local/soylatte16-i386-1.0.3//bin/java -XX:-PrintVMOptions -XX: 
+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx896m -Xms128m - 
XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/Users/ray/ 
Projects/OpenJDK/bsd-port/build/bsd-i586/langtools/dist/bootstrap/lib/ 
javac.jar -jar /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/ 
langtools/dist/bootstrap/lib/javac.jar -source 7 -target 7 -encoding  
ascii -Xbootclasspath:/Users/ray/Projects/OpenJDK/bsd-port/build/bsd- 
i586/classes -sourcepath /Users/ray/Projects/OpenJDK/bsd-port/build/ 
bsd-i586/gensrc:../../../src/solaris/classes:../../../src/share/ 
classes -d /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/classes  
@/Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/tmp/java/ 
java.lang/java/.classes.list.filtered

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
/bin/mkdir -p /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/tmp/ 
java/java.lang/java/obj
rm -f /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/tmp/java/ 
java.lang/java/obj/.class.headers.i586

# Running javah:
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586/bin/javah - 
bootclasspath /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/ 
classes -d /Users/ray/Projects/OpenJDK/bsd-port/build/bsd-i586/tmp/ 
java/java.lang/java/CClassHeaders/ \
		java.lang.Object java.lang.Class java.lang.Compiler java.lang.String  
java.lang.Thread java.lang.ThreadGroup java.lang.StrictMath  
java.lang.Number java.lang.Byte java.lang.Short java.lang.Integer  
java.lang.Long java.lang.Float java.lang.Double java.lang.Boolean  
java.lang.Character java.lang.System java.lang.ClassLoader  
java.lang.Runtime java.lang.SecurityManager java.lang.Shutdown  
java.lang.Package java.lang.ref.Finalizer  
java.lang.reflect.AccessibleObject java.lang.reflect.Field  
java.lang.reflect.Method java.lang.reflect.Constructor  
java.lang.reflect.InvocationTargetException java.lang.reflect.Array  
java.lang.reflect.Proxy java.security.AccessController java.util.Date  
java.util

hg: jdk7/build/langtools: Added tag jdk7-b75 for changeset 2485f5641ed0

2009-11-04 Thread kelly . ohair 
Changeset: c8083dc525b6
Author:mikejwre
Date:  2009-10-30 10:55 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/langtools/rev/c8083dc525b6

Added tag jdk7-b75 for changeset 2485f5641ed0

! .hgtags

hg: jdk7/build/jdk: 3 new changesets

2009-11-04 Thread kelly . ohair 
Changeset: 8885b2256507
Author:ohair
Date:  2009-10-29 11:17 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/jdk/rev/8885b2256507

6896472: Missing libjsig.so causes jdk build failure
Reviewed-by: tbell, kvn, phh

! make/java/redist/Makefile

Changeset: 185f51018a36
Author:mikejwre
Date:  2009-10-30 10:54 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/jdk/rev/185f51018a36

Added tag jdk7-b75 for changeset 8885b2256507

! .hgtags

Changeset: 7916c43cc007
Author:ohair
Date:  2009-11-04 11:19 -0800
URL:   http://hg.openjdk.java.net/jdk7/build/jdk/rev/7916c43cc007

Merge

! make/java/redist/Makefile

hg: jdk7/build/jaxws: Added tag jdk7-b75 for changeset fcf2b8b5d606

2009-11-04 Thread kelly . ohair 
Changeset: 27c05c2ad35f
Author:mikejwre
Date:  2009-10-30 10:54 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/jaxws/rev/27c05c2ad35f

Added tag jdk7-b75 for changeset fcf2b8b5d606

! .hgtags

hg: jdk7/build/jaxp: Added tag jdk7-b75 for changeset 555fb78ee4ce

2009-11-04 Thread kelly . ohair 
Changeset: cb7bd40f5031
Author:mikejwre
Date:  2009-10-30 10:54 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/jaxp/rev/cb7bd40f5031

Added tag jdk7-b75 for changeset 555fb78ee4ce

! .hgtags

hg: jdk7/build/hotspot: 31 new changesets

2009-11-04 Thread kelly . ohair 
Changeset: 528d98fe1037
Author:xlu
Date:  2009-09-24 12:10 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/528d98fe1037

6880029: JDK 1.6.0_u14p Application crashed very early
Reviewed-by: never, ysr, acorn

! src/share/vm/runtime/safepoint.cpp

Changeset: 054afbef9081
Author:acorn
Date:  2009-09-28 12:27 -0400
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/054afbef9081

Merge


Changeset: a2ad635573fb
Author:xlu
Date:  2009-10-14 12:40 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a2ad635573fb

Merge


Changeset: dcf03e02b020
Author:twisti
Date:  2009-10-06 02:11 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dcf03e02b020

6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845
Summary: For signatures with a large number of arguments the offset for the 
float store becomes too big and does not fit in 13-bit.
Reviewed-by: kvn, never

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
+ test/compiler/6879902/Test6879902.java

Changeset: 1ce3281a8e93
Author:kvn
Date:  2009-10-06 10:15 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1ce3281a8e93

6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC
Summary: Fix problem with the double register encodings in sparc.ad
Reviewed-by: never, jrose
Contributed-by: volker.simo...@gmail.com

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
+ test/compiler/6880034/Test6880034.java

Changeset: e90521d61f9a
Author:kvn
Date:  2009-10-07 12:43 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e90521d61f9a

6875959: CTW fails hotspot/src/share/vm/opto/reg_split.cpp:1087
Summary: To break spill ties choose bound live range over unbound to free 
register or one with smaller cost to spill.
Reviewed-by: never, jrose

! src/share/vm/opto/chaitin.cpp

Changeset: 03b336640699
Author:never
Date:  2009-10-07 15:38 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/03b336640699

6885584: A particular class structure causes large allocation spike for jit
Reviewed-by: kvn

! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
+ test/compiler/6885584/Test6885584.java

Changeset: 354d3184f6b2
Author:never
Date:  2009-10-13 12:04 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/hotspot/rev/354d3184f6b2

6890308: integrate zero assembler hotspot changes
Reviewed-by: never
Contributed-by: gben...@redhat.com

! make/Makefile
! make/defs.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/top.make
! make/linux/makefiles/vm.make
+ make/linux/makefiles/zero.make
+ make/linux/makefiles/zeroshark.make
+ make/linux/platform_zero.in
+ src/cpu/zero/vm/assembler_zero.cpp
+ src/cpu/zero/vm/assembler_zero.hpp
+ src/cpu/zero/vm/assembler_zero.inline.hpp
+ src/cpu/zero/vm/bytecodeInterpreter_zero.cpp
+ src/cpu/zero/vm/bytecodeInterpreter_zero.hpp
+ src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp
+ src/cpu/zero/vm/bytecodes_zero.cpp
+ src/cpu/zero/vm/bytecodes_zero.hpp
+ src/cpu/zero/vm/bytes_zero.hpp
+ src/cpu/zero/vm/codeBuffer_zero.hpp
+ src/cpu/zero/vm/copy_zero.hpp
+ src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp
+ src/cpu/zero/vm/cppInterpreter_zero.cpp
+ src/cpu/zero/vm/cppInterpreter_zero.hpp
+ src/cpu/zero/vm/debug_zero.cpp
+ src/cpu/zero/vm/depChecker_zero.cpp
+ src/cpu/zero/vm/depChecker_zero.hpp
+ src/cpu/zero/vm/disassembler_zero.cpp
+ src/cpu/zero/vm/disassembler_zero.hpp
+ src/cpu/zero/vm/dump_zero.cpp
+ src/cpu/zero/vm/entryFrame_zero.hpp
+ src/cpu/zero/vm/entry_zero.hpp
+ src/cpu/zero/vm/fakeStubFrame_zero.hpp
+ src/cpu/zero/vm/frame_zero.cpp
+ src/cpu/zero/vm/frame_zero.hpp
+ src/cpu/zero/vm/frame_zero.inline.hpp
+ src/cpu/zero/vm/globalDefinitions_zero.hpp
+ src/cpu/zero/vm/globals_zero.hpp
+ src/cpu/zero/vm/icBuffer_zero.cpp
+ src/cpu/zero/vm/icache_zero.cpp
+ src/cpu/zero/vm/icache_zero.hpp
+ src/cpu/zero/vm/interp_masm_zero.cpp
+ src/cpu/zero/vm/interp_masm_zero.hpp
+ src/cpu/zero/vm/interpreterFrame_zero.hpp
+ src/cpu/zero/vm/interpreterGenerator_zero.hpp
+ src/cpu/zero/vm/interpreterRT_zero.cpp
+ src/cpu/zero/vm/interpreterRT_zero.hpp
+ src/cpu/zero/vm/interpreter_zero.cpp
+ src/cpu/zero/vm/interpreter_zero.hpp
+ src/cpu/zero/vm/javaFrameAnchor_zero.hpp
+ src/cpu/zero/vm/jniFastGetField_zero.cpp
+ src/cpu/zero/vm/jniTypes_zero.hpp
+ src/cpu/zero/vm/jni_zero.h
+ src/cpu/zero/vm/methodHandles_zero.cpp
+ src/cpu/zero/vm/nativeInst_zero.cpp
+ src/cpu/zero/vm/nativeInst_zero.hpp
+ src/cpu/zero/vm/registerMap_zero.hpp
+ src/cpu/zero/vm/register_definitions_zero.cpp
+ src/cpu/zero/vm/register_zero.cpp
+ src/cpu/zero/vm/re

Re: Building OpenJDK Java 1.7.0 on Mac OS X 10.6

2009-11-04 Thread Maxim Porges 
I've diff'd a few of the files from that patch, and it looks like the  
code I have included the patch from jdk7-b47. I exported my local copy  
on September 23, 2009 from http://hg.openjdk.java.net/bsd-port/bsd- 
port, so my guess would be that it was around jdk7-b73 based on the  
tag dates.


	So, it looks like I have the current source, but it doesn't build on  
OS X 10.6.1. Does anybody know of a way to get the build working on OS  
X?


Thanks,

- max



On Sep 26, 2009, at 12:53 AM, Maxim Porges wrote:


Hmm, perhaps not. Thanks for the tip -I'll give it another shot with
this build.

- max


On Sep 25, 2009, at 1:20 PM, "John Coomes"   
wrote:



Maxim Porges (maxim.por...@highwinds.com) wrote:

Hi,

  I've been following Stephen Bannasch's very thorough and detailed
article 
(http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5
) for installing OpenJDK 1.7.0 on OS X (thanks very much to Stephen
for putting that together). I'm actually trying to install OpenJDK
1.7.0 on Snow Leopard 10.6, and it is almost working. Unfortunately,
it stops building about halfway through with the following error
message.

Compiling /Users/mporges/bsd-port/hotspot/src/share/vm/runtime/
arguments.cpp
...
cc1plus: warnings being treated as errors
/Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp:
In
static member function 'static void
Arguments::set_aggressive_opts_flags()':
/Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp:
1398: warning: format '%d' expects type 'int', but argument 3 has
type
'intx'
...


Do you have current source?  I believe this was fixed in jdk7-b47 by:

changeset:   511:2328d1d3f8cf
user:xlu
date:Wed Dec 24 19:13:53 2008 -0800
summary: 6781583: Hotspot build fails on linux 64 bit platform
with gcc 4.3.2

http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf

-John

hg: jdk7/build/corba: 2 new changesets

2009-11-04 Thread kelly . ohair 
Changeset: c8a56aff861b
Author:mikejwre
Date:  2009-10-30 10:54 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/corba/rev/c8a56aff861b

Added tag jdk7-b75 for changeset 0fb137085952

! .hgtags

Changeset: 6995f81e3b53
Author:ohair
Date:  2009-11-04 11:19 -0800
URL:   http://hg.openjdk.java.net/jdk7/build/corba/rev/6995f81e3b53

Merge

hg: jdk7/build: 2 new changesets

2009-11-04 Thread kelly . ohair 
Changeset: 2bad7eac71b3
Author:mikejwre
Date:  2009-10-30 10:54 -0700
URL:   http://hg.openjdk.java.net/jdk7/build/rev/2bad7eac71b3

Added tag jdk7-b75 for changeset d1516b9f2395

! .hgtags

Changeset: 0619361ff7c5
Author:ohair
Date:  2009-11-04 11:19 -0800
URL:   http://hg.openjdk.java.net/jdk7/build/rev/0619361ff7c5

Merge

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Andrew John Hughes 
2009/11/4 Kelly O'Hair :
>
>
> Andrew John Hughes wrote:
>>
>> 2009/11/4 Kelly O'Hair :
>>>
>>> I'm basically ok with this, but have one concern.
>>>
>>> There is no longer a default ant value for drops.dir, it is only
>>> set via the Makefile. Maybe that's ok, just not sure.
>>> I think it means that a plain 'ant' command will always download
>>> from the url. Again, maybe that's fine. So I'm ok with the push.
>>>
>>
>> Ah I see what you mean.  I changed things so all the logic was in one
>> place in the Makefile:
>>
>> ifdef ALT_DROPS_DIR
>>  DROPS_DIR = $(ALT_DROPS_DIR)
>> else
>>  ifdef ALT_JDK_DEVTOOLS_DIR
>>   DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
>>  else
>>   DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
>>  endif
>> endif
>>
>> so you get the same behaviour as before, but as you say, only when
>> running ant via the makefile.
>> Is ant ever run directly in this situation? I've never had reason to do
>> so.
>
> I do manually, and if you build via the NetBeans project. But the url
> usage should work.
>
>> Either way, I can add an updated version back to the build.xml.
>> That's not a problem, as we'll never use it.
>>
>> Can you allocate a bug ID so I can push? :)
>
> 6898251: Add ALT_DROPS_DIR feature to jaxp/jaxws
>
>
> -kto
>
>>
>>> I've learned to keep ant scripts out of the environment variable
>>> business if at all possible, so leaving any env var logic in
>>> the makefiles may be fine.
>>>
>>> Keeping the ant<->make boundaries simple seems like an essential
>>> thing to do, sigh, but is anything "simple" with ant scripts or
>>> Makefiles... :^(
>>>
>>
>> I know what you mean all too well... :(
>> At one point, I managed to have three different JDKs, all from
>> different vendors, involved in the building of langtools...
>>
>>> -kto
>>>
>>>
>>> Andrew John Hughes wrote:

 2009/10/28 Andrew John Hughes :

 snip..

> Well spotted; revised version here:
>
> http://cr.openjdk.java.net/~andrew/drops/webrev.03/

 Does this look ok to push?
>>
>> Thanks,
>

You've probably mentioned this before, but to which tree? I have it
applied to tl here for some reason I can't now remember...
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Kelly O'Hair 



Andrew John Hughes wrote:

2009/11/4 Kelly O'Hair :

I'm basically ok with this, but have one concern.

There is no longer a default ant value for drops.dir, it is only
set via the Makefile. Maybe that's ok, just not sure.
I think it means that a plain 'ant' command will always download
from the url. Again, maybe that's fine. So I'm ok with the push.



Ah I see what you mean.  I changed things so all the logic was in one
place in the Makefile:

ifdef ALT_DROPS_DIR
  DROPS_DIR = $(ALT_DROPS_DIR)
else
  ifdef ALT_JDK_DEVTOOLS_DIR
   DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
 else
   DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
 endif
endif

so you get the same behaviour as before, but as you say, only when
running ant via the makefile.
Is ant ever run directly in this situation? I've never had reason to do so.


I do manually, and if you build via the NetBeans project. But the url
usage should work.


Either way, I can add an updated version back to the build.xml.
That's not a problem, as we'll never use it.

Can you allocate a bug ID so I can push? :)


6898251: Add ALT_DROPS_DIR feature to jaxp/jaxws


-kto




I've learned to keep ant scripts out of the environment variable
business if at all possible, so leaving any env var logic in
the makefiles may be fine.

Keeping the ant<->make boundaries simple seems like an essential
thing to do, sigh, but is anything "simple" with ant scripts or
Makefiles... :^(



I know what you mean all too well... :(
At one point, I managed to have three different JDKs, all from
different vendors, involved in the building of langtools...


-kto


Andrew John Hughes wrote:

2009/10/28 Andrew John Hughes :

snip..


Well spotted; revised version here:

http://cr.openjdk.java.net/~andrew/drops/webrev.03/

Does this look ok to push?


Thanks,

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Andrew John Hughes 
2009/11/4 Kelly O'Hair :
>
> I'm basically ok with this, but have one concern.
>
> There is no longer a default ant value for drops.dir, it is only
> set via the Makefile. Maybe that's ok, just not sure.
> I think it means that a plain 'ant' command will always download
> from the url. Again, maybe that's fine. So I'm ok with the push.
>

Ah I see what you mean.  I changed things so all the logic was in one
place in the Makefile:

ifdef ALT_DROPS_DIR
  DROPS_DIR = $(ALT_DROPS_DIR)
else
  ifdef ALT_JDK_DEVTOOLS_DIR
   DROPS_DIR = $(ALT_JDK_DEVTOOLS_DIR)/share/jdk7-drops
 else
   DROPS_DIR = $(_SLASHJAVA)/devtools/share/jdk7-drops
 endif
endif

so you get the same behaviour as before, but as you say, only when
running ant via the makefile.
Is ant ever run directly in this situation? I've never had reason to do so.
Either way, I can add an updated version back to the build.xml.
That's not a problem, as we'll never use it.

Can you allocate a bug ID so I can push? :)

> I've learned to keep ant scripts out of the environment variable
> business if at all possible, so leaving any env var logic in
> the makefiles may be fine.
>
> Keeping the ant<->make boundaries simple seems like an essential
> thing to do, sigh, but is anything "simple" with ant scripts or
> Makefiles... :^(
>

I know what you mean all too well... :(
At one point, I managed to have three different JDKs, all from
different vendors, involved in the building of langtools...

> -kto
>
>
> Andrew John Hughes wrote:
>>
>> 2009/10/28 Andrew John Hughes :
>>
>> snip..
>>
>>> Well spotted; revised version here:
>>>
>>> http://cr.openjdk.java.net/~andrew/drops/webrev.03/
>>
>> Does this look ok to push?
>

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 



Alan Bateman wrote:

Kelly O'Hair wrote:

:
It was more of a balancing act on the test groupings with regards to 
timings
etc., and imageio did have "io" in it's name :^), and most of them ran 
safely
in samevm mode. So we can move them to any other group that is run in 
samevm

mode.  Do you have a better match than jdk_io?
It's probably best to group the image I/O tests with other tests in the 
client area. So far I see you've got jdk_awt and jdk_swing. Would the 
timing lean themselves to adding a new target or adding to one of the 
existing targets? If reducing the test list for jdk_io causes some 
unbalance then you could add to it the test list from jdk_nio1 (the 
java/nio/file tests) - they are in good shape and run quickly.




I'll move them to jdk_misc for now. Only 22 tests total anyway.

-kto


-Alan.

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Alan Bateman 

Kelly O'Hair wrote:

:
It was more of a balancing act on the test groupings with regards to 
timings
etc., and imageio did have "io" in it's name :^), and most of them ran 
safely
in samevm mode. So we can move them to any other group that is run in 
samevm

mode.  Do you have a better match than jdk_io?
It's probably best to group the image I/O tests with other tests in the 
client area. So far I see you've got jdk_awt and jdk_swing. Would the 
timing lean themselves to adding a new target or adding to one of the 
existing targets? If reducing the test list for jdk_io causes some 
unbalance then you could add to it the test list from jdk_nio1 (the 
java/nio/file tests) - they are in good shape and run quickly.


-Alan.

Re: 6856630: Restructure jaxp/jaxws repository

2009-11-04 Thread Kelly O'Hair 


I'm basically ok with this, but have one concern.

There is no longer a default ant value for drops.dir, it is only
set via the Makefile. Maybe that's ok, just not sure.
I think it means that a plain 'ant' command will always download
from the url. Again, maybe that's fine. So I'm ok with the push.

I've learned to keep ant scripts out of the environment variable
business if at all possible, so leaving any env var logic in
the makefiles may be fine.

Keeping the ant<->make boundaries simple seems like an essential
thing to do, sigh, but is anything "simple" with ant scripts or
Makefiles... :^(

-kto


Andrew John Hughes wrote:

2009/10/28 Andrew John Hughes :

snip..


Well spotted; revised version here:

http://cr.openjdk.java.net/~andrew/drops/webrev.03/


Does this look ok to push?

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Andrew John Hughes 
2009/11/4 Kelly O'Hair :
>
> I need some formal reviewers on these jdk/test/Makefile changes.
>
> More polish and changes may need to be done later, but there
> is value in what I have now, and I need lots of help to improve
> things (and fix some of our testcases).
>
> Here is the bugid and webrev:
>
> 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for
> use of samevm option
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/
>
> The goal was to see if we could easily run most of the regression
> tests in the jdk/test directory, in minimum time, and without so
> much noise (e.g. do not run unstable or problematic tests).
> This could then be used as a benchmark to validate some quality measure
> of the jdk7 that was built.
>
> The primary changes include:
>  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
>  * Addition of a jdk/test/ProblemList file to be used by jdk/test/Makefile
>
> I tried to group all the tests (by directory names) into jdk_* sets, then
> tried to balance them as to how long each set ran and if they could be run
> with the jtreg -samevm option. The balancing was tricky, and will need more
> polish, along with the virtual frame buffer idea. I also had to give up
> on the awt, rmi, and swing tests until the Xvfb issues are figured out.
>
> I chose to not actually modify the tests themselves if they needed fixing,
> it was just too overwhelming. So developers and teams may want to browse the
> ProblemList for their favorite tests (which aren't my favorites ;^) and
> consider what they might want to do.
>
> With this new jdk/test/Makefile, anybody can:
>
>  cd jdk/test
>  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] [JT_HOME=${YOUR_JTREG_HOME}]
> jdk_all
>
> And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
> machine isn't too slow and old. I was able to run it in 90 minutes on a
> monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.
>
> Then I added "-j 4" to the gnumake command line and it only took 30mins!
> So the various jdk_* make targets can be run in parallel.
>
> Please let me know what you think.
>
> -kto
>
>
>

I like this idea, the time to run a jdk jtreg test has put me off in the past.
BTW, jtreg is the one thing I wouldn't mind having in the tree as it's
not something people are likely to have installed.  IcedTea has a cut
down copy and that means tests get run.

I'm worried about the use of the IcedTea7 test list.  These were added
just because they were the ones that failed under my testing and
that's a while ago.  Just as may happen with your ProblemList, this
hasn't been maintained recently so I'd be wary about including the
list verbatim.

With this patch in, IcedTea7 can just use the list provided here.  We
don't use test/Makefile at present at all, and it would be nice to do
so.  I need to look at the issues with that.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 



Alan Bateman wrote:

Kelly O'Hair wrote:


I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm, 
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/ 



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
  * Addition of a jdk/test/ProblemList file to be used by 
jdk/test/Makefile


I tried to group all the tests (by directory names) into jdk_* sets, then
tried to balance them as to how long each set ran and if they could be 
run
with the jtreg -samevm option. The balancing was tricky, and will need 
more

polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.

I chose to not actually modify the tests themselves if they needed 
fixing,
it was just too overwhelming. So developers and teams may want to 
browse the

ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

  cd jdk/test
  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] 
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all


And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took 30mins!
So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

This looks really good. I don't see any obvious issues in the Makefile 
and I grabbed the patch to try it and it worked great.


My only concern is that ProblemList will require ongoing maintenance. I 
realize you don't want to get into changing tests and adding @ignore to 
unstable tests but I think you'll need to send a broadcast mail to make 
sure that folks know that their tests have problems in samevm mode, that 
they need to remove from ProblemList when fixing tests, maybe they need 
to add to ProblemList if changing/adding tests that take a long time, etc.


Yeah, but I didn't feel like I had many good solutions to this issue.

I'll maintain it to some degree, but I need the people that use this
makefile to help me out, and for everyone to start looking at why
their tests are even on this list.



For the groupings, then the only odd one I noticed is that jdk_io 
includes the javax/imagio tests. It would best to separate these as they 
are very different areas.


It was more of a balancing act on the test groupings with regards to timings
etc., and imageio did have "io" in it's name :^), and most of them ran safely
in samevm mode. So we can move them to any other group that is run in samevm
mode.  Do you have a better match than jdk_io?


-kto



-Alan.

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 



Tim Bell wrote:

Hi Kelly

I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).


This is a great start.


Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for use 
of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/

The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
   * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
   * Addition of a jdk/test/ProblemList file to be used by jdk/test/Makefile

I tried to group all the tests (by directory names) into jdk_* sets, then
tried to balance them as to how long each set ran and if they could be run
with the jtreg -samevm option. The balancing was tricky, and will need more
polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.


I wrote that start-Xvfb.sh script for you, but now I can see that I
need to take a closer look at it.  On recent OpenSolaris installs,
/usr/openwin is a symlink to /usr/X11, so my if test on line 20
is dubious at best.


I had to tweek that part of it, I wanted to favor /usr/X11, then go
after /usr/openwin.



I will take a look tomorrow and see if I can find a solution
that works better for Solaris 10, OpenSolaris, and Linux.


I got it working, I think, it was a little tricky to get it to die,
probably need a trap line in the script to make sure that when the
script dies, it takes the display and manager with it.

But the bigger problem was that the awt tests and even swing tests
seem to be able to bring the Xvfb down easily.





I chose to not actually modify the tests themselves if they needed fixing,
it was just too overwhelming. So developers and teams may want to browse the
ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

   cd jdk/test
   gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] [JT_HOME=${YOUR_JTREG_HOME}] jdk_all

And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.


For the record, that machine is a SunFire X2250 [1] which presents a total
of 16 2267 MHz CPUs to the O/S.  Kelly, Kumar, and I have been dumping work
on this system for almost a week.  It hasn't blinked - it grinds through
everything we throw at it.  I am impressed by what our Sun hardware colleagues
have been able to squeeze into one rack unit.  A few years ago, a server this
powerful would have been as large as a microwave oven, if not a refrigerator.
Thanks are due to the Sun lab managers who recently gave us two of these for
JDK7 use.


Then I added "-j 4" to the gnumake command line and it only took 30mins!
So the various jdk_* make targets can be run in parallel.


Very cool!  I have never attempted that before, with any of our test
suites.  In the past, too many tests left dirt behind and caused
many innocent test that might run later to fail...


Getting 3,000+ stable tests run in 30mins will be handy.

Managing the ProblemList (as Jon noted) will be a pain at times.

-kto



Tim

[1] Community info:  
http://www.sun.com/bigadmin/hcl/data/systems/details/9521.html
Sales info: http://www.sun.com/servers/x64/x2250/

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 



Martin Buchholz wrote:

One of the things you've done is to create "test sets".
I did something like that in my "jtr" script (ask Tim if you can't find it).
For each logical component, it's non-trivial to find all the tests
for that (e.g. how to test string handling). 
This is especially true for shared directories like java/lang

and java/util.  I don't think there's much value in creating a special
target for testing java/util, since
1) jtreg can do that easily already
2) this doesn't match the job of any particular technology developer


With the jtreg options I set in the Makefile, there is a big
difference between just running 'jtreg java/util' vs. 'make jdk_util'.
The Makefile will exclude problem tests and @ignore tests, and
will use -samevm (which is not the jtreg default).
So I can somewhat guarantee that if all is good with the world,
'make jdk_util' will be 100% pass, and run as quickly as possible.

That's what started me on this road, running 'jtreg java/util' is
slow and unstable, and most of all, when it finishes I don't really
know if it was a good result or a bad result.

Don't mean to pick on java/util, the same is true with any of these
batches. I kept wondering, "I got N failures, is that good?" :^(

And with -samevm, it is valuable to run "test sets" as a way of
isolating the possible problems with tests sharing a VM.



What would be really useful is to try to fix all the tests
that fail under -samevm (perhaps by marking them
@run othervm)


I started down that road myself and fell into a big rat hole. :^(
Modifying tests requires a buy in from those teams, and just the
logistics of that effort was more than I had the time for.

Also, it's not clear that just making them run othervm is the
right thing to do in some cases. In talking to some developers,
some want to go the extra mile to make the test samevm safe,
others don't. Some don't want to, or have the time, to do anything
to their tests. So it's a large mix of attitudes and plans on how
to deal with it.

So the ProblemList was my answer, and a testcase checklist for teams
that want to fix their tests, and then delete the lines from ProblemList.

I'll probably try and fix some of the tests I'm familiar with in
the future, like the serviceability tests.

-kto



Martin

On Tue, Nov 3, 2009 at 18:03, Kelly O'Hair > wrote:



I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm,
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
 * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
 * Addition of a jdk/test/ProblemList file to be used by
jdk/test/Makefile

I tried to group all the tests (by directory names) into jdk_* sets,
then
tried to balance them as to how long each set ran and if they could
be run
with the jtreg -samevm option. The balancing was tricky, and will
need more
polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.

I chose to not actually modify the tests themselves if they needed
fixing,
it was just too overwhelming. So developers and teams may want to
browse the
ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

 cd jdk/test
 gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}]
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all

And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took 30mins!
So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Jonathan Gibbons 

Kelly O'Hair wrote:



Jonathan Gibbons wrote:

Kelly,

Wow, you've been busy.

The thing that stood out to me was the use of SLASH_JAVA which is 
something of a Sun legacy which doesn't apply to folk outside Sun.  
And, looking at the file as a whole, it's clear there are many 
different sections, not all of which apply to the OpenJDK 
community.   Would it not help to split this file up into sections 
for the various test suites, or at least into a couple of files like 
jtreg.gmk and other.gmk so that people outside Sun have a better 
chance of figuring out this file.


I took a stab at creating *.gmk files and did not like the result.
Separating this stuff into separate make include files just makes it
harder to maintain in my opinion. Completely separate Makefile's just 
seemed
like more work than it was worth. The sections on jck and vmsqe are 
isolated

as best I can in the one file, I didn't think that was so bad.

One big Makefile has some big advantages, for now, I'd like to leave 
it that way.


-kto


OK. Thanks for trying.

-- Jon





-- Jon


Kelly O'Hair wrote:


I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm, 
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/ 



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio 
...
  * Addition of a jdk/test/ProblemList file to be used by 
jdk/test/Makefile


I tried to group all the tests (by directory names) into jdk_* sets, 
then
tried to balance them as to how long each set ran and if they could 
be run
with the jtreg -samevm option. The balancing was tricky, and will 
need more

polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.

I chose to not actually modify the tests themselves if they needed 
fixing,
it was just too overwhelming. So developers and teams may want to 
browse the

ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

  cd jdk/test
  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] 
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all


And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took 
30mins!

So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Kelly O'Hair 



Jonathan Gibbons wrote:

Kelly,

Wow, you've been busy.

The thing that stood out to me was the use of SLASH_JAVA which is 
something of a Sun legacy which doesn't apply to folk outside Sun.  And, 
looking at the file as a whole, it's clear there are many different 
sections, not all of which apply to the OpenJDK community.   Would it 
not help to split this file up into sections for the various test 
suites, or at least into a couple of files like jtreg.gmk and other.gmk 
so that people outside Sun have a better chance of figuring out this file.


I took a stab at creating *.gmk files and did not like the result.
Separating this stuff into separate make include files just makes it
harder to maintain in my opinion. Completely separate Makefile's just seemed
like more work than it was worth. The sections on jck and vmsqe are isolated
as best I can in the one file, I didn't think that was so bad.

One big Makefile has some big advantages, for now, I'd like to leave it that 
way.

-kto



-- Jon


Kelly O'Hair wrote:


I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm, 
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/ 



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
  * Addition of a jdk/test/ProblemList file to be used by 
jdk/test/Makefile


I tried to group all the tests (by directory names) into jdk_* sets, then
tried to balance them as to how long each set ran and if they could be 
run
with the jtreg -samevm option. The balancing was tricky, and will need 
more

polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.

I chose to not actually modify the tests themselves if they needed 
fixing,
it was just too overwhelming. So developers and teams may want to 
browse the

ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

  cd jdk/test
  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] 
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all


And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took 30mins!
So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Jonathan Gibbons 

Martin,

It would be wrong to *just* mark the broken tests as @run othervm, 
because then we would have no obvious way to distinguish between those 
tests which are intentionally othervm, and those tests which should be 
samevm but which are broken and have to be othervm "for now". 

It would be better to also mark such tests in some other way as well, 
perhaps using a keyword, so that such tests can be easily identified and 
tracked.


-- Jon

Martin Buchholz wrote:

One of the things you've done is to create "test sets".
I did something like that in my "jtr" script (ask Tim if you can't 
find it).

For each logical component, it's non-trivial to find all the tests
for that (e.g. how to test string handling). 
This is especially true for shared directories like java/lang

and java/util.  I don't think there's much value in creating a special
target for testing java/util, since
1) jtreg can do that easily already
2) this doesn't match the job of any particular technology developer

What would be really useful is to try to fix all the tests
that fail under -samevm (perhaps by marking them
@run othervm)

Martin

On Tue, Nov 3, 2009 at 18:03, Kelly O'Hair > wrote:



I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm,
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality
measure
of the jdk7 that was built.

The primary changes include:
 * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util
jdk_nio ...
 * Addition of a jdk/test/ProblemList file to be used by
jdk/test/Makefile

I tried to group all the tests (by directory names) into jdk_*
sets, then
tried to balance them as to how long each set ran and if they
could be run
with the jtreg -samevm option. The balancing was tricky, and will
need more
polish, along with the virtual frame buffer idea. I also had to
give up
on the awt, rmi, and swing tests until the Xvfb issues are figured
out.

I chose to not actually modify the tests themselves if they needed
fixing,
it was just too overwhelming. So developers and teams may want to
browse the
ProblemList for their favorite tests (which aren't my favorites
;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

 cd jdk/test
 gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}]
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all

And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes
on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took
30mins!
So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

Re: Need reviewers - jdk testing changes 6888927

2009-11-04 Thread Alan Bateman 

Kelly O'Hair wrote:


I need some formal reviewers on these jdk/test/Makefile changes.

More polish and changes may need to be done later, but there
is value in what I have now, and I need lots of help to improve
things (and fix some of our testcases).

Here is the bugid and webrev:

6888927: Fix jdk jtreg tests to indicate which ones need othervm, 
allow for use of samevm option
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/ 



The goal was to see if we could easily run most of the regression
tests in the jdk/test directory, in minimum time, and without so
much noise (e.g. do not run unstable or problematic tests).
This could then be used as a benchmark to validate some quality measure
of the jdk7 that was built.

The primary changes include:
  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
  * Addition of a jdk/test/ProblemList file to be used by 
jdk/test/Makefile


I tried to group all the tests (by directory names) into jdk_* sets, then
tried to balance them as to how long each set ran and if they could be 
run
with the jtreg -samevm option. The balancing was tricky, and will need 
more

polish, along with the virtual frame buffer idea. I also had to give up
on the awt, rmi, and swing tests until the Xvfb issues are figured out.

I chose to not actually modify the tests themselves if they needed 
fixing,
it was just too overwhelming. So developers and teams may want to 
browse the

ProblemList for their favorite tests (which aren't my favorites ;^) and
consider what they might want to do.

With this new jdk/test/Makefile, anybody can:

  cd jdk/test
  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] 
[JT_HOME=${YOUR_JTREG_HOME}] jdk_all


And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
machine isn't too slow and old. I was able to run it in 90 minutes on a
monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.

Then I added "-j 4" to the gnumake command line and it only took 30mins!
So the various jdk_* make targets can be run in parallel.

Please let me know what you think.

-kto

This looks really good. I don't see any obvious issues in the Makefile 
and I grabbed the patch to try it and it worked great.


My only concern is that ProblemList will require ongoing maintenance. I 
realize you don't want to get into changing tests and adding @ignore to 
unstable tests but I think you'll need to send a broadcast mail to make 
sure that folks know that their tests have problems in samevm mode, that 
they need to remove from ProblemList when fixing tests, maybe they need 
to add to ProblemList if changing/adding tests that take a long time, etc.


For the groupings, then the only odd one I noticed is that jdk_io 
includes the javax/imagio tests. It would best to separate these as they 
are very different areas.


-Alan.