Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On 2013-06-19 03:10, Stuart Marks wrote: -- I have half a mind to look at the Configure changes myself in my spare time (ha!), but I have no spare time, and I don't have the expertise in this area anyway. So anyone is welcome to pick this up. In principle it should be fairly simple, and I think it's fairly important. This isn't the first time someone's been bitten by having the wrong boot JDK version, and it won't be the last. Currently, configure checks that the found boot jdk is 7 or 8. Do we really want to actively prevent using 8 all together? I could agree to printing a big warning in the summary at the end of configure to discourage it, but I do believe it necessary to have the ability to build with 8 for tracking down certain bugs. Regarding the rearrangement of corba/jaxp/jaxws to use the fresh JDK instead of the boot JDK. At least we know they build, because the boot cycle build builds them successfully. (At least, I think it does.) Now, I don't think the artifacts produced from a boot cycle build are actually tested or are delivered anywhere in a bundle. So, while it seems quite unlikely, some bugs could have been introduced by building with a newer JDK version. Now ... circular dependencies ... urk ... I *knew* there was something that would make this complicated. Well, maybe these will need to be refactored away somehow. Or maybe some kind of GenStubs technique can be used to deal with the circularity. You introduced yet another point as well, which is the relationship between the repository organization and the build structure. As I understand things, each repository has its own build support and builds in a separate step from the others. In principle I think that the repository structure ought to be orthogonal to the build structure. At least, if we move to a more modular build structure, that shouldn't imply that we need to have each module in its own repository. In fact I'd like to see fewer repositories. To me, the only compelling reason to have a separate repo is if the source code in it is a snapshot of an upstream source base -- as seems to be the case for jaxws. Having all the stuff in fewer repos makes it easier to bisect to find failures, and it reduces the need for careful management of coordinated, cross-repo changes. My preferred solution would be to fold in the repos that aren't upstream projects into jdk and just have them compile with the rest there. I much like the idea of reducing the number of repos. If that isn't possible, we can just add those source directories to the main javac invocation in jdk too. /Erik
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On 19/06/2013 09:01, Erik Joelsson wrote: : My preferred solution would be to fold in the repos that aren't upstream projects into jdk and just have them compile with the rest there. I much like the idea of reducing the number of repos. If that isn't possible, we can just add those source directories to the main javac invocation in jdk too. I think the repo structure does need to be re-examined. While I don't think we want a repository per module, I do think we should at least consider the implication of having the code organized by modules. Also one of the benefits of the ongoing efforts to remove dependencies from the core on other areas is that it opens up the possibility of other structures (I've heard Jon suggest a core repository for the core language and runtime for example). In any case, I think a first step is to move the build of the jaxws repository to later in the build. It's an upstream project and nothing in the JDK should have any dependencies on the code in that repository. Note to self: test moving JAX-WS/JAXB/SAAJ/JAF from rt.jar to the extensions directory and see what comes out of the woodwork. I'm not sure what to say about the corba repository. There is sad history and what we have in OpenJDK is essentially a fork of the CORBA code that is in Glassfish. There have been suggestions over the years to bring the code together but I don't know whether this is possible now (or even it is worth it). -Alan
RE: HSX-25: Code Review (round 0) request for MacOS X exported symbols fix (8014326)
Dan
These changes look good.
Ron
-Original Message-
From: Daniel D. Daugherty
Sent: Tuesday, June 18, 2013 2:30 PM
To: hotspot-runtime-...@openjdk.java.net; build-dev
Subject: HSX-25: Code Review (round 0) request for MacOS X exported symbols
fix (8014326)
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014326
https://jbs.oracle.com/bugs/browse/JDK-8014326
Here are the HSX-25 webrev URLs:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8014326-webrev/0-hsx25/
Internal: http://javaweb.us.oracle.com/~ddaugher/8014326-webrev/0-hsx25/
Testing:
- JPRT test job on MacOS X
- (in process) Aurora Adhoc vm.quick batch for MacOS X in the following
configs: {Server VM} x {fastdebug} x {-Xmixed}
Gory details are below. As always, comments, questions and suggestions are
welome.
Dan
Gory Details:
The script and Makefile changes are easy to review via the webrev.
However, every function name in the MacOS X mapfiles had to be modified to
match the MacOS X symbol
export syntax. I created normalized
copies of the mapfiles in order to compare the semantic changes (and ignore
the syntactic changes).
These diffs are added to bug report, but JBS is not yet accessible outside
Oracle and bugs.sun.com can
be slow to update so I've included the diffs here.
mapfile-vers-debug: current BSD versus updated BSD
$ diff bsd-funcs-debug{.orig,}
195a196
JVM_SetNativeThreadName
219,236d219
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
248,250d230
fork1
numa_warn
numa_error
252,254d231
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 196: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
mapfile-vers-product: current BSD versus updated BSD
$ diff bsd-funcs-product{.orig,}
195a196
JVM_SetNativeThreadName
219,236d219
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
243,245d225
fork1
numa_warn
numa_error
247,249d226
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 196: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
Since the MacOS X port was originally derived from the Linux port, it also
makes sense to compare the
updated BSD files versus the current Linux files. This is a useful sanity
check.
mapfile-vers-debug: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-debug
218c218
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
230a231,233
fork1
numa_warn
numa_error
231a235,237
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 218 is an obvious rename.
Lines 231-233 are functions not compiled into BSD/MacOS X.
Line 236 is an error on Linux; sysThreadAvailableStackWithSlack is only on
Solaris, but we won't fix
that with this bug since we want the MacOS X fix in HSX24 and in HSX25.
mapfile-vers-product: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-product
218c218
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
225a226,228
fork1
numa_warn
numa_error
226a230,232
# Needed because there is no JVM interface for this.
RE: HSX-24: Code Review (round 0) request for MacOS X exported symbols fix (8014326)
Dan
These changes look good.
Ron
-Original Message-
From: Daniel D. Daugherty
Sent: Tuesday, June 18, 2013 2:50 PM
To: hotspot-runtime-...@openjdk.java.net; build-dev
Subject: HSX-24: Code Review (round 0) request for MacOS X exported symbols
fix (8014326)
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014326
https://jbs.oracle.com/bugs/browse/JDK-8014326
Here are the HSX-24 backport webrev URLs:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8014326-webrev/0-hsx24/
Internal: http://javaweb.us.oracle.com/~ddaugher/8014326-webrev/0-hsx24/
Testing:
- JPRT test job on MacOS X
- (in process) Aurora Adhoc vm.quick batch for MacOS X in the following
configs: {Server VM} x {fastdebug} x {-Xmixed}
Gory details are below. As always, comments, questions and suggestions are
welome.
Dan
Gory Details:
The script and Makefile changes are easy to review via the webrev.
However, every function name in the MacOS X mapfiles had to be modified to
match the MacOS X symbol
export syntax. I created normalized
copies of the mapfiles in order to compare the semantic changes (and ignore
the syntactic changes).
These diffs are added to bug report, but JBS is not yet accessible outside
Oracle and bugs.sun.com can
be slow to update so I've included the diffs here.
mapfile-vers-debug: current BSD versus updated BSD
$ diff bsd-funcs-debug{.orig,}
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
mapfile-vers-product: current BSD versus updated BSD
$ diff bsd-funcs-product.orig bsd-funcs-product
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
Since the MacOS X port was originally derived from the Linux port, it also
makes sense to compare the
updated BSD files versus the current Linux files. This is a useful sanity
check.
mapfile-vers-debug: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-debug
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
226a227,229
fork1
numa_warn
numa_error
227a231,233
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 214 is an obvious rename.
Lines 227-229 are functions not compiled into BSD/MacOS X.
Line 232 is an error on Linux; sysThreadAvailableStackWithSlack is only on
Solaris, but we won't fix
that with this bug since we want the MacOS X fix in HSX24 and in HSX25.
mapfile-vers-product: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-product
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
221a222,224
fork1
numa_warn
numa_error
222a226,228
# Needed because there is no JVM
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
I'm not sure how big a warning needs to be to make people aware of it. Is it possible to create another configure option like --yes-i-do-want-to-use-n that you must add to set boot jdk to 8? --Max On 6/19/2013 5:23 PM, Chris Hegarty wrote: On 19/06/2013 09:01, Erik Joelsson wrote: On 2013-06-19 03:10, Stuart Marks wrote: -- I have half a mind to look at the Configure changes myself in my spare time (ha!), but I have no spare time, and I don't have the expertise in this area anyway. So anyone is welcome to pick this up. In principle it should be fairly simple, and I think it's fairly important. This isn't the first time someone's been bitten by having the wrong boot JDK version, and it won't be the last. Currently, configure checks that the found boot jdk is 7 or 8. Do we really want to actively prevent using 8 all together? I could agree to printing a big warning in the summary at the end of configure to discourage it, but I do believe it necessary to have the ability to build with 8 for tracking down certain bugs. +1 -Chris.
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On 6/19/2013 4:01 PM, Erik Joelsson wrote: Now ... circular dependencies ... urk ... I *knew* there was something that would make this complicated. Well, maybe these will need to be refactored away somehow. Or maybe some kind of GenStubs technique can be used to deal with the circularity. We can create skeleton classes to deal with circular dependencies. It's like .h files for Java. --Max
Re: HSX-24: Code Review (round 0) request for MacOS X exported symbols fix (8014326)
Ron,
Thanks for the review.
Dan
On 6/19/13 7:39 AM, Ron Durbin wrote:
Dan
These changes look good.
Ron
-Original Message-
From: Daniel D. Daugherty
Sent: Tuesday, June 18, 2013 2:50 PM
To: hotspot-runtime-...@openjdk.java.net; build-dev
Subject: HSX-24: Code Review (round 0) request for MacOS X exported symbols fix
(8014326)
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014326
https://jbs.oracle.com/bugs/browse/JDK-8014326
Here are the HSX-24 backport webrev URLs:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8014326-webrev/0-hsx24/
Internal: http://javaweb.us.oracle.com/~ddaugher/8014326-webrev/0-hsx24/
Testing:
- JPRT test job on MacOS X
- (in process) Aurora Adhoc vm.quick batch for MacOS X in the following
configs: {Server VM} x {fastdebug} x {-Xmixed}
Gory details are below. As always, comments, questions and suggestions are
welome.
Dan
Gory Details:
The script and Makefile changes are easy to review via the webrev.
However, every function name in the MacOS X mapfiles had to be modified to
match the MacOS X symbol
export syntax. I created normalized
copies of the mapfiles in order to compare the semantic changes (and ignore the
syntactic changes).
These diffs are added to bug report, but JBS is not yet accessible outside
Oracle and bugs.sun.com can
be slow to update so I've included the diffs here.
mapfile-vers-debug: current BSD versus updated BSD
$ diff bsd-funcs-debug{.orig,}
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
mapfile-vers-product: current BSD versus updated BSD
$ diff bsd-funcs-product.orig bsd-funcs-product
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
Since the MacOS X port was originally derived from the Linux port, it also
makes sense to compare the
updated BSD files versus the current Linux files. This is a useful sanity check.
mapfile-vers-debug: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-debug
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
226a227,229
fork1
numa_warn
numa_error
227a231,233
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 214 is an obvious rename.
Lines 227-229 are functions not compiled into BSD/MacOS X.
Line 232 is an error on Linux; sysThreadAvailableStackWithSlack is only on
Solaris, but we won't fix
that with this bug since we want the MacOS X fix in HSX24 and in HSX25.
mapfile-vers-product: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-product
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
221a222,224
fork1
numa_warn
numa_error
222a226,228
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 214 is an obvious
Re: HSX-25: Code Review (round 0) request for MacOS X exported symbols fix (8014326)
Ron,
Thanks for the review (HSX-25 version).
Dan
On 6/19/13 7:40 AM, Ron Durbin wrote:
Dan
These changes look good.
Ron
-Original Message-
From: Daniel D. Daugherty
Sent: Tuesday, June 18, 2013 2:30 PM
To: hotspot-runtime-...@openjdk.java.net; build-dev
Subject: HSX-25: Code Review (round 0) request for MacOS X exported symbols fix
(8014326)
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014326
https://jbs.oracle.com/bugs/browse/JDK-8014326
Here are the HSX-25 webrev URLs:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8014326-webrev/0-hsx25/
Internal: http://javaweb.us.oracle.com/~ddaugher/8014326-webrev/0-hsx25/
Testing:
- JPRT test job on MacOS X
- (in process) Aurora Adhoc vm.quick batch for MacOS X in the following
configs: {Server VM} x {fastdebug} x {-Xmixed}
Gory details are below. As always, comments, questions and suggestions are
welome.
Dan
Gory Details:
The script and Makefile changes are easy to review via the webrev.
However, every function name in the MacOS X mapfiles had to be modified to
match the MacOS X symbol
export syntax. I created normalized
copies of the mapfiles in order to compare the semantic changes (and ignore the
syntactic changes).
These diffs are added to bug report, but JBS is not yet accessible outside
Oracle and bugs.sun.com can
be slow to update so I've included the diffs here.
mapfile-vers-debug: current BSD versus updated BSD
$ diff bsd-funcs-debug{.orig,}
195a196
JVM_SetNativeThreadName
219,236d219
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
248,250d230
fork1
numa_warn
numa_error
252,254d231
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 196: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
mapfile-vers-product: current BSD versus updated BSD
$ diff bsd-funcs-product{.orig,}
195a196
JVM_SetNativeThreadName
219,236d219
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4 # but
their code has not been
removed yet because there will not # be a substantial code savings until
JVM_InvokeMethod and #
JVM_NewInstanceFromConstructor can also be removed; see #
reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
243,245d225
fork1
numa_warn
numa_error
247,249d226
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 196: add missing JVM_SetNativeThreadName entry Delete the old reflection
routines!
Delete other functions not compiled into BSD/MacOS X.
Since the MacOS X port was originally derived from the Linux port, it also
makes sense to compare the
updated BSD files versus the current Linux files. This is a useful sanity check.
mapfile-vers-debug: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-debug
218c218
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
230a231,233
fork1
numa_warn
numa_error
231a235,237
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 218 is an obvious rename.
Lines 231-233 are functions not compiled into BSD/MacOS X.
Line 236 is an error on Linux; sysThreadAvailableStackWithSlack is only on
Solaris, but we won't fix
that with this bug since we want the MacOS X fix in HSX24 and in HSX25.
mapfile-vers-product: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-product
218c218
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
225a226,228
fork1
numa_warn
numa_error
226a230,232
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 218 is an obvious rename.
Re: HSX-24: Code Review (round 0) request for MacOS X exported symbols fix (8014326)
Thanks for the reviews!
Dan
On 6/19/13 1:58 PM, Coleen Phillimore wrote:
Dan,
This looks good!
Coleen
On 6/18/2013 4:50 PM, Daniel D. Daugherty wrote:
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014326
https://jbs.oracle.com/bugs/browse/JDK-8014326
Here are the HSX-24 backport webrev URLs:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8014326-webrev/0-hsx24/
Internal: http://javaweb.us.oracle.com/~ddaugher/8014326-webrev/0-hsx24/
Testing:
- JPRT test job on MacOS X
- (in process) Aurora Adhoc vm.quick batch for MacOS X in the following
configs: {Server VM} x {fastdebug} x {-Xmixed}
Gory details are below. As always, comments, questions and
suggestions are welome.
Dan
Gory Details:
The script and Makefile changes are easy to review via the webrev.
However, every function name in the MacOS X mapfiles had to be modified
to match the MacOS X symbol export syntax. I created normalized
copies of the mapfiles in order to compare the semantic changes (and
ignore the syntactic changes). These diffs are added to bug report,
but JBS is not yet accessible outside Oracle and bugs.sun.com can
be slow to update so I've included the diffs here.
mapfile-vers-debug: current BSD versus updated BSD
$ diff bsd-funcs-debug{.orig,}
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4
# but their code has not been removed yet because there will not
# be a substantial code savings until JVM_InvokeMethod and
# JVM_NewInstanceFromConstructor can also be removed; see
# reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry
Delete the old reflection routines!
Delete other functions not compiled into BSD/MacOS X.
mapfile-vers-product: current BSD versus updated BSD
$ diff bsd-funcs-product.orig bsd-funcs-product
191a192
JVM_SetNativeThreadName
215,232d215
# Old reflection routines
# These do not need to be present in the product build in JDK 1.4
# but their code has not been removed yet because there will not
# be a substantial code savings until JVM_InvokeMethod and
# JVM_NewInstanceFromConstructor can also be removed; see
# reflectionCompat.hpp.
JVM_GetClassConstructor
JVM_GetClassConstructors
JVM_GetClassField
JVM_GetClassFields
JVM_GetClassMethod
JVM_GetClassMethods
JVM_GetField
JVM_GetPrimitiveField
JVM_NewInstance
JVM_SetField
JVM_SetPrimitiveField
239,241d221
fork1
numa_warn
numa_error
243,245d222
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 192: add missing JVM_SetNativeThreadName entry
Delete the old reflection routines!
Delete other functions not compiled into BSD/MacOS X.
Since the MacOS X port was originally derived from the Linux port,
it also makes sense to compare the updated BSD files versus the
current Linux files. This is a useful sanity check.
mapfile-vers-debug: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-debug
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
226a227,229
fork1
numa_warn
numa_error
227a231,233
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 214 is an obvious rename.
Lines 227-229 are functions not compiled into BSD/MacOS X.
Line 232 is an error on Linux; sysThreadAvailableStackWithSlack is
only on Solaris, but we won't fix that with this bug since we want
the MacOS X fix in HSX24 and in HSX25.
mapfile-vers-product: updated BSD versus current Linux
$ diff {bsd,linux}-funcs-product
214c214
JVM_handle_bsd_signal
---
JVM_handle_linux_signal
221a222,224
fork1
numa_warn
numa_error
222a226,228
# Needed because there is no JVM interface for this.
sysThreadAvailableStackWithSlack
Line 214 is an obvious rename.
Lines 222-224 are functions not compiled into BSD/MacOS X.
Line 227 is an error on Linux; sysThreadAvailableStackWithSlack is
only on Solaris, but we won't fix that with this bug since we want
the MacOS X fix in HSX24 and in HSX25.
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On 6/19/13 1:01 AM, Erik Joelsson wrote: Currently, configure checks that the found boot jdk is 7 or 8. Do we really want to actively prevent using 8 all together? I could agree to printing a big warning in the summary at the end of configure to discourage it, but I do believe it necessary to have the ability to build with 8 for tracking down certain bugs. Right. This is mainly about preventing mistakes, such as a run of configure that picks up a JDK 8 that might happen to be in one's path, or someone who's not aware of the rule I just clarified in the README. :-) But of course it should be possible to configure JDK 8 as the boot for JDK 8 if necessary. I'm not sure a warning is sufficient. To paraphrase Kelly's message from earlier, Rule #1 Nobody pays attention to any warnings Rule #2 When things go wrong, claim that you didn't see the warning I looked in boot-jdk.m4 and I see that it disallows JDK 6 entirely (makes sense) and allows 7 and 8. Maybe it could disallow JDK 8 by default, unless an additional option is provided (like Max suggested). Of course, all of these numbers will need to be rolled forward when we get to JDK 9. s'marks Regarding the rearrangement of corba/jaxp/jaxws to use the fresh JDK instead of the boot JDK. At least we know they build, because the boot cycle build builds them successfully. (At least, I think it does.) Now, I don't think the artifacts produced from a boot cycle build are actually tested or are delivered anywhere in a bundle. So, while it seems quite unlikely, some bugs could have been introduced by building with a newer JDK version. Now ... circular dependencies ... urk ... I *knew* there was something that would make this complicated. Well, maybe these will need to be refactored away somehow. Or maybe some kind of GenStubs technique can be used to deal with the circularity. You introduced yet another point as well, which is the relationship between the repository organization and the build structure. As I understand things, each repository has its own build support and builds in a separate step from the others. In principle I think that the repository structure ought to be orthogonal to the build structure. At least, if we move to a more modular build structure, that shouldn't imply that we need to have each module in its own repository. In fact I'd like to see fewer repositories. To me, the only compelling reason to have a separate repo is if the source code in it is a snapshot of an upstream source base -- as seems to be the case for jaxws. Having all the stuff in fewer repos makes it easier to bisect to find failures, and it reduces the need for careful management of coordinated, cross-repo changes. My preferred solution would be to fold in the repos that aren't upstream projects into jdk and just have them compile with the rest there. I much like the idea of reducing the number of repos. If that isn't possible, we can just add those source directories to the main javac invocation in jdk too. /Erik
Re: RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
On Jun 17, 2013, at 5:21 PM, Stuart Marks wrote: Hi Kelly! You still read this stuff here? :-) I read anything that looks entertaining from entertaining people. ;^) -kto
jdk8-lambda builds failing in hotspot for all platforms ( thread.hpp )
All the jdk8-lambda nightly builds failed tonight, in hotspot, in thread.hpp https://jbs.oracle.com/bugs/browse/JDK-8017117 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017117 Thanks Dave http://rehudson.us.oracle.com:8080/hudson/job/2-build-solaris-sparc/2106/console /localtools/solaris-sparc/SUNWspro/SS12u1/prod/bin/CC -DSOLARIS -DSPARC_WORKS -DSPARC -DPRODUCT -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/precompiled -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/posix/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION=\25.0-b34\ -DHOTSPOT_BUILD_TARGET=\product\ -DHOTSPOT_BUILD_USER=\\ -DHOTSPOT_LIB_ARCH=\sparc\ -DHOTSPOT_VM_DISTRO=\Java HotSpot(TM)\ -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_solaris_sparc -DTARGET_OS_ARCH_MODEL_solaris_sparc -DTARGET_COMPILER_sparcWorks -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -xmemalign=4s -m32 -xarch=sparc /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.il -template=no%extdef -features=no%split_init -D_Crun_inline_placement -library=%none -KPIC -mt -xdebugformat=stabs -xO4 -g0 -xs -xwe -features=no%except -DINCLUDE_TRACE -DHAVE_DTRACE_H -DDTRACE_ENABLED -c -xMMD -xMF ../generated/dependencies/ad_sparc.o.d -o ad_sparc.o ../generated/adfiles/ad_sparc.cpp /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [accessFlags.o] Error 5 gmake[6]: *** Waiting for unfinished jobs /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [abstractCompiler.o] Error 5 /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [ad_sparc.o] Error 5 gmake[6]: Leaving directory
Re: jdk8-lambda builds failing in hotspot for all platforms ( thread.hpp )
I have pushed a sync of jdk8 b94 to lambda/hotspot. This should resolve the issue. Mike On Jun 19 2013, at 19:20 , David Katleman wrote: All the jdk8-lambda nightly builds failed tonight, in hotspot, in thread.hpp https://jbs.oracle.com/bugs/browse/JDK-8017117 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017117 Thanks Dave http://rehudson.us.oracle.com:8080/hudson/job/2-build-solaris-sparc/2106/console /localtools/solaris-sparc/SUNWspro/SS12u1/prod/bin/CC -DSOLARIS -DSPARC_WORKS -DSPARC -DPRODUCT -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/precompiled -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/posix/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION=\25.0-b34\ -DHOTSPOT_BUILD_TARGET=\product\ -DHOTSPOT_BUILD_USER=\\ -DHOTSPOT_LIB_ARCH=\sparc\ -DHOTSPOT_VM_DISTRO=\Java HotSpot(TM)\ -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_solaris_sparc -DTARGET_OS_ARCH_MODEL_solaris_sparc -DTARGET_COMPILER_sparcWorks -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -xmemalign=4s -m32 -xarch=sparc /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.il -template=no%extdef -features=no%split_init -D_Crun_inline_placement -library=%none -KPIC -mt -xdebugformat=stabs -xO4 -g0 -xs -xwe -features=no%except -DINCLUDE_TRACE -DHAVE_DTRACE_H -DDTRACE_ENABLED -c -xMMD -xMF ../generated/dependencies/ad_sparc.o.d -o ad_sparc.o ../generated/adfiles/ad_sparc.cpp /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [accessFlags.o] Error 5 gmake[6]: *** Waiting for unfinished jobs /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [abstractCompiler.o] Error 5 /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp,
Re: jdk8-lambda builds failing in hotspot for all platforms ( thread.hpp )
On 6/19/2013 8:18 PM, Mike Duigou wrote: I have pushed a sync of jdk8 b94 to lambda/hotspot. This should resolve the issue. Thanks Mike, I've started another build Dave On Jun 19 2013, at 19:20 , David Katleman wrote: All the jdk8-lambda nightly builds failed tonight, in hotspot, in thread.hpp https://jbs.oracle.com/bugs/browse/JDK-8017117 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017117 Thanks Dave http://rehudson.us.oracle.com:8080/hudson/job/2-build-solaris-sparc/2106/console /localtools/solaris-sparc/SUNWspro/SS12u1/prod/bin/CC -DSOLARIS -DSPARC_WORKS -DSPARC -DPRODUCT -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/prims -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/precompiled -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/cpu/sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/solaris/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/closed/os/posix/vm -I/HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION=\25.0-b34\ -DHOTSPOT_BUILD_TARGET=\product\ -DHOTSPOT_BUILD_USER=\\ -DHOTSPOT_LIB_ARCH=\sparc\ -DHOTSPOT_VM_DISTRO=\Java HotSpot(TM)\ -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_solaris_sparc -DTARGET_OS_ARCH_MODEL_solaris_sparc -DTARGET_COMPILER_sparcWorks -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -xmemalign=4s -m32 -xarch=sparc /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.il -template=no%extdef -features=no%split_init -D_Crun_inline_placement -library=%none -KPIC -mt -xdebugformat=stabs -xO4 -g0 -xs -xwe -features=no%except -DINCLUDE_TRACE -DHAVE_DTRACE_H -DDTRACE_ENABLED -c -xMMD -xMF ../generated/dependencies/ad_sparc.o.d -o ad_sparc.o ../generated/adfiles/ad_sparc.cpp /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [accessFlags.o] Error 5 gmake[6]: *** Waiting for unfinished jobs /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: TRACE_BUFFER is not defined. 5 Error(s) detected. gmake[6]: *** [abstractCompiler.o] Error 5 /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 261: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Type name expected instead of TRACE_BUFFER. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 452: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line 453: Error: Use ; to terminate declarations. /HUDSON2/workspace/2-build-solaris-sparc/jdk8-lambda/4843/hotspot/src/share/vm/runtime/thread.hpp, line
