From paul.hohensee at oracle.com Wed Feb 1 04:12:40 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 01 Feb 2012 07:12:40 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120131152335.GA7700@redhat.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120131152335.GA7700@redhat.com> Message-ID: <4F292C38.5010901@oracle.com> linux-sparc used to build and run fine (I did the port way back when), so it should be relatively easy to resurrect. The original port was on a T1. Paul On 1/31/12 10:23 AM, Deepak Bhole wrote: > * David Holmes [2012-01-30 21:50]: >> On 31/01/2012 12:36 PM, Deepak Bhole wrote: >>> * David Holmes [2012-01-30 19:57]: >>>> While gcc compilation on sparc is rare I'm not sure that simply >>>> deleting the sparc-only option unconditionally is the right thing to >>>> do. >>>> >>> I thought about that too. But I was unable to find info on OpenJDK + >>> SPARC + Linux. Is that combination even supported? The README doesn't >>> list it: >>> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE >> Linux-sparc is not one of Oracle's supported OpenJDK platforms. >> However AFAIK there are people in the community building OpenJDK on >> Linux-sparc using the Zero interpreter. I don't know if this would >> affect them but it still seems to me that we should be careful not >> to break other people's builds. >> > Ah fair enough. If it is supported, the patch definitely needs to be > fixed. I will re-post. > > Thanks for taking a look! > > Deepak > >> David >> ----- >> >>> The option seemed more like a relic from Solaris + SPARC config rather >>> than a requirement for Linux + SPARC. >> >> >>> Cheers, >>> Deepak >>> >>>> David >>>> >>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>> Hi, >>>>> >>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>> checking. >>>>> >>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain >>>>> files in JDK supply the -mimpure-text option to GCC. This option is only >>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build >>>>> on Linux (I suppose . >>>>> >>>>> This patch removes the option: >>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>> >>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>> >>>>> If OK for push, please feel free to do so (I don't have commit access). >>>>> >>>>> Cheers, >>>>> Deepak From paul.hohensee at oracle.com Wed Feb 1 04:13:28 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 01 Feb 2012 07:13:28 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F292C38.5010901@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120131152335.GA7700@redhat.com> <4F292C38.5010901@oracle.com> Message-ID: <4F292C68.60407@oracle.com> On, and it's not supported by Oracle, of course. One of the Linux distro companies might be interested though. On 2/1/12 7:12 AM, Paul Hohensee wrote: > linux-sparc used to build and run fine (I did the port way back when), > so it should be relatively easy to resurrect. The original port was on > a T1. > > Paul > > On 1/31/12 10:23 AM, Deepak Bhole wrote: >> * David Holmes [2012-01-30 21:50]: >>> On 31/01/2012 12:36 PM, Deepak Bhole wrote: >>>> * David Holmes [2012-01-30 19:57]: >>>>> While gcc compilation on sparc is rare I'm not sure that simply >>>>> deleting the sparc-only option unconditionally is the right thing to >>>>> do. >>>>> >>>> I thought about that too. But I was unable to find info on OpenJDK + >>>> SPARC + Linux. Is that combination even supported? The README doesn't >>>> list it: >>>> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE >>>> >>> Linux-sparc is not one of Oracle's supported OpenJDK platforms. >>> However AFAIK there are people in the community building OpenJDK on >>> Linux-sparc using the Zero interpreter. I don't know if this would >>> affect them but it still seems to me that we should be careful not >>> to break other people's builds. >>> >> Ah fair enough. If it is supported, the patch definitely needs to be >> fixed. I will re-post. >> >> Thanks for taking a look! >> >> Deepak >> >>> David >>> ----- >>> >>>> The option seemed more like a relic from Solaris + SPARC config rather >>>> than a requirement for Linux + SPARC. >>> >>> >>>> Cheers, >>>> Deepak >>>> >>>>> David >>>>> >>>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>>> Hi, >>>>>> >>>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>>> checking. >>>>>> >>>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. >>>>>> Certain >>>>>> files in JDK supply the -mimpure-text option to GCC. This option >>>>>> is only >>>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during >>>>>> build >>>>>> on Linux (I suppose . >>>>>> >>>>>> This patch removes the option: >>>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>>> >>>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>>> 2: >>>>>> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>>> >>>>>> If OK for push, please feel free to do so (I don't have commit >>>>>> access). >>>>>> >>>>>> Cheers, >>>>>> Deepak From frederic.parain at oracle.com Wed Feb 1 06:41:59 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 01 Feb 2012 14:41:59 +0000 Subject: hg: jdk8/tl/jdk: 7120974: ManagementPermission "control" needs clarification Message-ID: <20120201144209.CB370472DA@hg.openjdk.java.net> Changeset: ac26d04e76c3 Author: fparain Date: 2012-02-01 03:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac26d04e76c3 7120974: ManagementPermission "control" needs clarification Reviewed-by: mchung, dholmes ! src/share/classes/java/lang/management/ManagementPermission.java From staffan.larsen at oracle.com Wed Feb 1 08:05:12 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Feb 2012 17:05:12 +0100 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set Message-ID: Please review the following change. webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. If the user sets -Djava.io.tmpdir to something else than /tmp, the attach framework will fail (for example jstack). The reason is that Hotspot and the jdk does not agree on which directory the well-known .java_pid and .attach_pid files should be in. On OSX Hotspot will always create these in the per-user secure temporary directory, but the jdk will look in java.io.tmpdir. This fix makes sure the jdk looks in the same location as Hotspot. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120201/c6943e23/attachment-0001.html From daniel.daugherty at oracle.com Wed Feb 1 14:59:32 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 15:59:32 -0700 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set In-Reply-To: References: Message-ID: <4F29C3D4.1040609@oracle.com> On 2/1/12 9:05 AM, Staffan Larsen wrote: > Please review the following change. > > webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 > > This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. > > If the user sets -Djava.io.tmpdir to something else than /tmp, the attach framework will fail (for example jstack). The reason is that Hotspot and the jdk does not agree on which directory the well-known .java_pid and .attach_pid files should be in. On OSX Hotspot will always create these in the per-user secure temporary directory, but the jdk will look in java.io.tmpdir. > > This fix makes sure the jdk looks in the same location as Hotspot. > > Thanks, > /Staffan Please update copyright years to 2012. src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java line 73: Always creates the ".attach_pid" file in tmpdir. The HSX side matches this and always looks for the ".attach_pid" file in tmpdir. Perhaps we should change Linux and Solaris to always create and look for the ".attach_pid" file in tmpdir... src/solaris/native/sun/tools/attach/BsdVirtualMachine.c No comments. From daniel.daugherty at oracle.com Wed Feb 1 15:01:35 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 16:01:35 -0700 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set In-Reply-To: <4F29C3D4.1040609@oracle.com> References: <4F29C3D4.1040609@oracle.com> Message-ID: <4F29C44F.5030406@oracle.com> Forgot to say: Thumbs up! Dan On 2/1/12 3:59 PM, Daniel D. Daugherty wrote: > On 2/1/12 9:05 AM, Staffan Larsen wrote: >> Please review the following change. >> >> webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 >> >> This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. >> >> If the user sets -Djava.io.tmpdir to something else than /tmp, the >> attach framework will fail (for example jstack). The reason is that >> Hotspot and the jdk does not agree on which directory the well-known >> .java_pid and .attach_pid files should be in. On OSX Hotspot will >> always create these in the per-user secure temporary directory, but >> the jdk will look in java.io.tmpdir. >> >> This fix makes sure the jdk looks in the same location as Hotspot. >> >> Thanks, >> /Staffan > > Please update copyright years to 2012. > > src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java > line 73: Always creates the ".attach_pid" file in tmpdir. > The HSX side matches this and always looks for the > ".attach_pid" file in tmpdir. Perhaps we should change > Linux and Solaris to always create and look for the > ".attach_pid" file in tmpdir... > > src/solaris/native/sun/tools/attach/BsdVirtualMachine.c > No comments. From bradford.wetmore at oracle.com Wed Feb 1 16:01:09 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 02 Feb 2012 00:01:09 +0000 Subject: hg: jdk8/tl/jdk: 7141910: Incorrect copyright dates on new test cases. Message-ID: <20120202000134.BD9E2472E6@hg.openjdk.java.net> Changeset: 55a82eba1986 Author: wetmore Date: 2012-02-01 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55a82eba1986 7141910: Incorrect copyright dates on new test cases. Reviewed-by: mullan ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh From paul.hohensee at oracle.com Wed Feb 1 18:46:38 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Thu, 02 Feb 2012 02:46:38 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Message-ID: <20120202024649.C6EBE472FB@hg.openjdk.java.net> Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make From david.holmes at oracle.com Wed Feb 1 20:15:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Feb 2012 14:15:36 +1000 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F28070A.9070007@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> <4F27FB6B.2080406@oracle.com> <4F28070A.9070007@oracle.com> Message-ID: <4F2A0DE8.9050705@oracle.com> This fix has been pushed but Dan's comments seem to indicate there is a problem. I confess I can't keep track of which functions are creating and/or looking for which file in which location and which VM is doing the creating/looking. David On 1/02/2012 1:21 AM, Daniel D. Daugherty wrote: > Summary: The .java_pid socket/door is always created in the > os::get_temp_directory() which is "/tmp" on BSD, Linux and > Solaris. On MacOS X, it can be either the "secure per-user > temporary directory" or "/tmp". > > The .attach_pid file is created by the Java side > createAttachFile(). That code first tries to create the > file in the process' working directory and if that fails, > then it attempts to create the file in tmpdir. > > src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java > lines 40-44: The new comment is right for .java_pid, but > not quite right for .attach_pid. See createAttachFile() > method on line 280; .attach_pid creation is first > attempted in the Java process' current working dir > and then in tmpdir. > > src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java > lines 41-45: The new comment is right for .java_pid, but > not quite right for .attach_pid. See createAttachFile() > method on line 215; .attach_pid creation is first > attempted in the Java process' current working dir > and then in tmpdir. > > test/ProblemList.txt > No comments. > > > Linux HSX gory details: > > The following block of code only creates the .java_pid socket in the > directory named by os::get_temp_directory(). On Linux, that function > is hardcoded to return "/tmp". > > src/os/linux/vm/attachListener_linux.cpp: > > 170 // Initialization - create a listener socket and bind it to a file > 171 > 172 int LinuxAttachListener::init() { > 173 char path[UNIX_PATH_MAX]; // socket file > 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup > 175 int listener; // listener socket (file descriptor > ) > 176 > 177 // register function to cleanup > 178 ::atexit(listener_cleanup); > 179 > 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", > 181 os::get_temp_directory(), os::current_process_id()); > 182 if (n < (int)UNIX_PATH_MAX) { > 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); > 184 } > 185 if (n >= (int)UNIX_PATH_MAX) { > 186 return -1; > 187 } > > This block of code checks the process' current directory for an .attach_pid > file before it checks os::get_temp_directory(). However, that check is > just to see if the attach mechanism should be started. If it does get > spoofed, there is little harm. > > 464 // If the file .attach_pid exists in the working directory > 465 // or /tmp then this is the trigger to start the attach mechanism > 466 bool AttachListener::is_init_trigger() { > 467 if (init_at_startup() || is_initialized()) { > 468 return false; // initialized at startup or already ini > tialized > 469 } > 470 char fn[PATH_MAX+1]; > 471 sprintf(fn, ".attach_pid%d", os::current_process_id()); > 472 int ret; > 473 struct stat64 st; > 474 RESTARTABLE(::stat64(fn, &st), ret); > 475 if (ret == -1) { > 476 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > 477 os::get_temp_directory(), os::current_process_id()); > 478 RESTARTABLE(::stat64(fn, &st), ret); > 479 } > 480 if (ret == 0) { > 481 // simple check to avoid starting the attach mechanism when > 482 // a bogus user creates the file > 483 if (st.st_uid == geteuid()) { > 484 init(); > 485 return true; > 486 } > 487 } > 488 return false; > 489 } > > > Solaris HSX gory details: > > This code assumes both files are always in /tmp/...: > > src/os/solaris/dtrace/jvm_dtrace.c > > 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" > 171 > 172 /* fill-in the name of attach file name in given buffer */ > 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { > 174 memset(path, 0, len); > 175 sprintf(path, ATTACH_FILE_PATTERN, pid); > 176 } > 177 > 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" > 179 > 180 /* open door file for the given JVM */ > 181 static int open_door(pid_t pid) { > 182 char path[PATH_MAX + 1]; > 183 int fd; > 184 > 185 sprintf(path, DOOR_FILE_PATTERN, pid); > 186 fd = file_open(path, O_RDONLY); > 187 if (fd < 0) { > 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); > 189 print_debug("cannot open door file %s\n", path); > 190 return -1; > 191 } > 192 print_debug("opened door file %s\n", path); > 193 if (check_permission(path) != 0) { > 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); > 195 print_debug("check permission failed for %s\n", path); > 196 file_close(fd); > 197 fd = -1; > 198 } > 199 return fd; > 200 } > 201 > 202 /* create attach file for given process */ > 203 static int create_attach_file(pid_t pid) { > 204 char path[PATH_MAX + 1]; > 205 int fd; > 206 fill_attach_file_name(path, sizeof(path), pid); > 207 fd = file_open(path, O_CREAT | O_RDWR); > 208 if (fd < 0) { > 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); > 210 print_debug("cannot create file %s\n", path); > 211 } else { > 212 print_debug("created attach file %s\n", path); > 213 } > 214 return fd; > 215 } > > The following block of code only creates the .java_pid door in the > directory named by os::get_temp_directory(). On Solaris, that function > is hardcoded to return "/tmp". > > src/os/solaris/vm/attachListener_solaris.cpp > > 367 // Create the door > 368 int SolarisAttachListener::create_door() { > 369 char door_path[PATH_MAX+1]; > 370 char initial_path[PATH_MAX+1]; > 371 int fd, res; > 372 > 373 // register exit function > 374 ::atexit(listener_cleanup); > 375 > 376 // create the door descriptor > 377 int dd = ::door_create(enqueue_proc, NULL, 0); > 378 if (dd < 0) { > 379 return -1; > 380 } > 381 > 382 // create initial file to attach door descriptor > 383 snprintf(door_path, sizeof(door_path), "%s/.java_pid%d", > 384 os::get_temp_directory(), os::current_process_id()); > 385 snprintf(initial_path, sizeof(initial_path), "%s.tmp", door_path); > 386 RESTARTABLE(::creat(initial_path, S_IRUSR | S_IWUSR), fd); > 387 if (fd == -1) { > 388 debug_only(warning("attempt to create %s failed", initial_path)); > 389 ::door_revoke(dd); > 390 return -1; > 391 } > 392 assert(fd >= 0, "bad file descriptor"); > 393 RESTARTABLE(::close(fd), res); > > This block of code checks the process' current directory for an .attach_pid > file before it checks os::get_temp_directory(). However, that check is > just to see if the attach mechanism should be started. If it does get > spoofed, there is little harm. > > 603 // If the file .attach_pid exists in the working directory > 604 // or /tmp then this is the trigger to start the attach mechanism > 605 bool AttachListener::is_init_trigger() { > 606 if (init_at_startup() || is_initialized()) { > 607 return false; // initialized at startup or already ini > tialized > 608 } > 609 char fn[PATH_MAX+1]; > 610 sprintf(fn, ".attach_pid%d", os::current_process_id()); > 611 int ret; > 612 struct stat64 st; > 613 RESTARTABLE(::stat64(fn, &st), ret); > 614 if (ret == -1) { > 615 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > 616 os::get_temp_directory(), os::current_process_id()); > 617 RESTARTABLE(::stat64(fn, &st), ret); > 618 } > 619 if (ret == 0) { > 620 // simple check to avoid starting the attach mechanism when > 621 // a bogus user creates the file > 622 if (st.st_uid == geteuid()) { > 623 init(); > 624 return true; > 625 } > 626 } > 627 return false; > 628 } > > > BSD/MacOS X HSX gory details: > > This code assumes both files are always in /tmp/...: > > src/os/bsd/dtrace/jvm_dtrace.c > > 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" > 171 > 172 /* fill-in the name of attach file name in given buffer */ > 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { > 174 memset(path, 0, len); > 175 sprintf(path, ATTACH_FILE_PATTERN, pid); > 176 } > 177 > 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" > 179 > 180 /* open door file for the given JVM */ > 181 static int open_door(pid_t pid) { > 182 char path[PATH_MAX + 1]; > 183 int fd; > 184 > 185 sprintf(path, DOOR_FILE_PATTERN, pid); > 186 fd = file_open(path, O_RDONLY); > 187 if (fd < 0) { > 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); > 189 print_debug("cannot open door file %s\n", path); > 190 return -1; > 191 } > 192 print_debug("opened door file %s\n", path); > 193 if (check_permission(path) != 0) { > 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); > 195 print_debug("check permission failed for %s\n", path); > 196 file_close(fd); > 197 fd = -1; > 198 } > 199 return fd; > 200 } > 201 > 202 /* create attach file for given process */ > 203 static int create_attach_file(pid_t pid) { > 204 char path[PATH_MAX + 1]; > 205 int fd; > 206 fill_attach_file_name(path, sizeof(path), pid); > 207 fd = file_open(path, O_CREAT | O_RDWR); > 208 if (fd < 0) { > 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); > 210 print_debug("cannot create file %s\n", path); > 211 } else { > 212 print_debug("created attach file %s\n", path); > 213 } > 214 return fd; > 215 } > > The following block of code only creates the .java_pid socket in the > directory named by os::get_temp_directory(). On BSD, that function > is hardcoded to return "/tmp". On MacOS X, that function returns > the path of the "secure per-user temporary directory" if one is > configured or "/tmp" if one is not. > > src/os/bsd/vm/attachListener_bsd.cpp > > 170 // Initialization - create a listener socket and bind it to a file > 171 > 172 int BsdAttachListener::init() { > 173 char path[UNIX_PATH_MAX]; // socket file > 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup > 175 int listener; // listener socket (file descriptor > ) > 176 > 177 // register function to cleanup > 178 ::atexit(listener_cleanup); > 179 > 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", > 181 os::get_temp_directory(), os::current_process_id()); > 182 if (n < (int)UNIX_PATH_MAX) { > 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); > 184 } > 185 if (n >= (int)UNIX_PATH_MAX) { > 186 return -1; > 187 } > > This block of code checks the process' current directory for an .attach_pid > file before it checks os::get_temp_directory(). However, that check is > just to see if the attach mechanism should be started. If it does get > spoofed, there is little harm. > > 476 // If the file .attach_pid exists in the working directory > 477 // or /tmp then this is the trigger to start the attach mechanism > 478 bool AttachListener::is_init_trigger() { > 479 if (init_at_startup() || is_initialized()) { > 480 return false; // initialized at startup or already ini > tialized > 481 } > 482 char path[PATH_MAX + 1]; > 483 int ret; > 484 struct stat st; > 485 > 486 snprintf(path, PATH_MAX + 1, "%s/.attach_pid%d", > 487 os::get_temp_directory(), os::current_process_id()); > 488 RESTARTABLE(::stat(path, &st), ret); > 489 if (ret == 0) { > 490 // simple check to avoid starting the attach mechanism when > 491 // a bogus user creates the file > 492 if (st.st_uid == geteuid()) { > 493 init(); > 494 return true; > 495 } > 496 } > 497 return false; > 498 } > > > > On 1/31/12 7:32 AM, Daniel D. Daugherty wrote: >> Sorry, sent that last one as "reply to list" instead of "reply to all"... >> >> I think you need to hold up on this one. I don't think the >> assumption that .java_pid and .attach_pid files are always >> in /tmp is a good one. >> >> More in a little bit. >> >> Dan >> >> On 1/31/12 1:10 AM, Staffan Larsen wrote: >>> Moving "/tmp" to a static field, made it easier to write a comment >>> explaining the rationale as well. >>> >>> Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ >>> >>> >>> Thanks, >>> /Staffan >>> >>> On 31 jan 2012, at 01:23, David Holmes wrote: >>> >>>> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>>>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>>>> for it. >>>>>> >>>>>> I don't agree that this would make the code easier to read or >>>>>> maintain. >>>>>> I should, however, include a comment saying that the file is >>>>>> always in >>>>>> /tmp regardless of the value of java.io.tmpdir. >>>> >>>> Staffan: I still think changing the static field tmpdir to refer to >>>> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >>>> >>>>> /tmp is common but not mandatory, especially if we speak about >>>>> embedded >>>>> systems. >>>> >>>> Dmitry: The point is that the VM will always put the file in /tmp. >>>> That's wrong but the issue here is making the management Java code >>>> match the hotspot code. >>>> >>>>> Native code should use P_tmpdir constant from stdio.h rather than >>>>> hardcode "/tmp". >>>>> >>>>> As we can't access it from java I recommend to create a global >>>>> constant >>>>> somewhere to reduce possible future porting efforts. >>>>> >>>>> >>>>>> Changing the tmpdir static would be a smaller fix, but all the cwd >>>>>> code >>>>>> would then remain. Yes, HotSpot never writes to cwd. >>>>> >>>>> I agree with Staffan, that looks for socket/door in cwd should be >>>>> removed. >>>> >>>> Ok, if it is never needed then remove it. >>>> >>>> David >>>> >>>>> -Dmitry >>>>> >>> From daniel.daugherty at oracle.com Wed Feb 1 22:04:24 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 23:04:24 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F2A0DE8.9050705@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> <4F27FB6B.2080406@oracle.com> <4F28070A.9070007@oracle.com> <4F2A0DE8.9050705@oracle.com> Message-ID: <4F2A2768.2060201@oracle.com> The problem is only with comments. Staffan and I discussed this off thread. Dan On 2/1/12 9:15 PM, David Holmes wrote: > This fix has been pushed but Dan's comments seem to indicate there is > a problem. I confess I can't keep track of which functions are > creating and/or looking for which file in which location and which VM > is doing the creating/looking. > > David > > On 1/02/2012 1:21 AM, Daniel D. Daugherty wrote: >> Summary: The .java_pid socket/door is always created in the >> os::get_temp_directory() which is "/tmp" on BSD, Linux and >> Solaris. On MacOS X, it can be either the "secure per-user >> temporary directory" or "/tmp". >> >> The .attach_pid file is created by the Java side >> createAttachFile(). That code first tries to create the >> file in the process' working directory and if that fails, >> then it attempts to create the file in tmpdir. >> >> src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java >> lines 40-44: The new comment is right for .java_pid, but >> not quite right for .attach_pid. See createAttachFile() >> method on line 280; .attach_pid creation is first >> attempted in the Java process' current working dir >> and then in tmpdir. >> >> src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java >> lines 41-45: The new comment is right for .java_pid, but >> not quite right for .attach_pid. See createAttachFile() >> method on line 215; .attach_pid creation is first >> attempted in the Java process' current working dir >> and then in tmpdir. >> >> test/ProblemList.txt >> No comments. >> >> >> Linux HSX gory details: >> >> The following block of code only creates the .java_pid socket in the >> directory named by os::get_temp_directory(). On Linux, that function >> is hardcoded to return "/tmp". >> >> src/os/linux/vm/attachListener_linux.cpp: >> >> 170 // Initialization - create a listener socket and bind it to a file >> 171 >> 172 int LinuxAttachListener::init() { >> 173 char path[UNIX_PATH_MAX]; // socket file >> 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup >> 175 int listener; // listener socket (file descriptor >> ) >> 176 >> 177 // register function to cleanup >> 178 ::atexit(listener_cleanup); >> 179 >> 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", >> 181 os::get_temp_directory(), os::current_process_id()); >> 182 if (n < (int)UNIX_PATH_MAX) { >> 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); >> 184 } >> 185 if (n >= (int)UNIX_PATH_MAX) { >> 186 return -1; >> 187 } >> >> This block of code checks the process' current directory for an >> .attach_pid >> file before it checks os::get_temp_directory(). However, that check is >> just to see if the attach mechanism should be started. If it does get >> spoofed, there is little harm. >> >> 464 // If the file .attach_pid exists in the working directory >> 465 // or /tmp then this is the trigger to start the attach mechanism >> 466 bool AttachListener::is_init_trigger() { >> 467 if (init_at_startup() || is_initialized()) { >> 468 return false; // initialized at startup or already ini >> tialized >> 469 } >> 470 char fn[PATH_MAX+1]; >> 471 sprintf(fn, ".attach_pid%d", os::current_process_id()); >> 472 int ret; >> 473 struct stat64 st; >> 474 RESTARTABLE(::stat64(fn, &st), ret); >> 475 if (ret == -1) { >> 476 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> 477 os::get_temp_directory(), os::current_process_id()); >> 478 RESTARTABLE(::stat64(fn, &st), ret); >> 479 } >> 480 if (ret == 0) { >> 481 // simple check to avoid starting the attach mechanism when >> 482 // a bogus user creates the file >> 483 if (st.st_uid == geteuid()) { >> 484 init(); >> 485 return true; >> 486 } >> 487 } >> 488 return false; >> 489 } >> >> >> Solaris HSX gory details: >> >> This code assumes both files are always in /tmp/...: >> >> src/os/solaris/dtrace/jvm_dtrace.c >> >> 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" >> 171 >> 172 /* fill-in the name of attach file name in given buffer */ >> 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { >> 174 memset(path, 0, len); >> 175 sprintf(path, ATTACH_FILE_PATTERN, pid); >> 176 } >> 177 >> 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" >> 179 >> 180 /* open door file for the given JVM */ >> 181 static int open_door(pid_t pid) { >> 182 char path[PATH_MAX + 1]; >> 183 int fd; >> 184 >> 185 sprintf(path, DOOR_FILE_PATTERN, pid); >> 186 fd = file_open(path, O_RDONLY); >> 187 if (fd < 0) { >> 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); >> 189 print_debug("cannot open door file %s\n", path); >> 190 return -1; >> 191 } >> 192 print_debug("opened door file %s\n", path); >> 193 if (check_permission(path) != 0) { >> 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); >> 195 print_debug("check permission failed for %s\n", path); >> 196 file_close(fd); >> 197 fd = -1; >> 198 } >> 199 return fd; >> 200 } >> 201 >> 202 /* create attach file for given process */ >> 203 static int create_attach_file(pid_t pid) { >> 204 char path[PATH_MAX + 1]; >> 205 int fd; >> 206 fill_attach_file_name(path, sizeof(path), pid); >> 207 fd = file_open(path, O_CREAT | O_RDWR); >> 208 if (fd < 0) { >> 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); >> 210 print_debug("cannot create file %s\n", path); >> 211 } else { >> 212 print_debug("created attach file %s\n", path); >> 213 } >> 214 return fd; >> 215 } >> >> The following block of code only creates the .java_pid door in the >> directory named by os::get_temp_directory(). On Solaris, that function >> is hardcoded to return "/tmp". >> >> src/os/solaris/vm/attachListener_solaris.cpp >> >> 367 // Create the door >> 368 int SolarisAttachListener::create_door() { >> 369 char door_path[PATH_MAX+1]; >> 370 char initial_path[PATH_MAX+1]; >> 371 int fd, res; >> 372 >> 373 // register exit function >> 374 ::atexit(listener_cleanup); >> 375 >> 376 // create the door descriptor >> 377 int dd = ::door_create(enqueue_proc, NULL, 0); >> 378 if (dd < 0) { >> 379 return -1; >> 380 } >> 381 >> 382 // create initial file to attach door descriptor >> 383 snprintf(door_path, sizeof(door_path), "%s/.java_pid%d", >> 384 os::get_temp_directory(), os::current_process_id()); >> 385 snprintf(initial_path, sizeof(initial_path), "%s.tmp", door_path); >> 386 RESTARTABLE(::creat(initial_path, S_IRUSR | S_IWUSR), fd); >> 387 if (fd == -1) { >> 388 debug_only(warning("attempt to create %s failed", initial_path)); >> 389 ::door_revoke(dd); >> 390 return -1; >> 391 } >> 392 assert(fd >= 0, "bad file descriptor"); >> 393 RESTARTABLE(::close(fd), res); >> >> This block of code checks the process' current directory for an >> .attach_pid >> file before it checks os::get_temp_directory(). However, that check is >> just to see if the attach mechanism should be started. If it does get >> spoofed, there is little harm. >> >> 603 // If the file .attach_pid exists in the working directory >> 604 // or /tmp then this is the trigger to start the attach mechanism >> 605 bool AttachListener::is_init_trigger() { >> 606 if (init_at_startup() || is_initialized()) { >> 607 return false; // initialized at startup or already ini >> tialized >> 608 } >> 609 char fn[PATH_MAX+1]; >> 610 sprintf(fn, ".attach_pid%d", os::current_process_id()); >> 611 int ret; >> 612 struct stat64 st; >> 613 RESTARTABLE(::stat64(fn, &st), ret); >> 614 if (ret == -1) { >> 615 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> 616 os::get_temp_directory(), os::current_process_id()); >> 617 RESTARTABLE(::stat64(fn, &st), ret); >> 618 } >> 619 if (ret == 0) { >> 620 // simple check to avoid starting the attach mechanism when >> 621 // a bogus user creates the file >> 622 if (st.st_uid == geteuid()) { >> 623 init(); >> 624 return true; >> 625 } >> 626 } >> 627 return false; >> 628 } >> >> >> BSD/MacOS X HSX gory details: >> >> This code assumes both files are always in /tmp/...: >> >> src/os/bsd/dtrace/jvm_dtrace.c >> >> 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" >> 171 >> 172 /* fill-in the name of attach file name in given buffer */ >> 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { >> 174 memset(path, 0, len); >> 175 sprintf(path, ATTACH_FILE_PATTERN, pid); >> 176 } >> 177 >> 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" >> 179 >> 180 /* open door file for the given JVM */ >> 181 static int open_door(pid_t pid) { >> 182 char path[PATH_MAX + 1]; >> 183 int fd; >> 184 >> 185 sprintf(path, DOOR_FILE_PATTERN, pid); >> 186 fd = file_open(path, O_RDONLY); >> 187 if (fd < 0) { >> 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); >> 189 print_debug("cannot open door file %s\n", path); >> 190 return -1; >> 191 } >> 192 print_debug("opened door file %s\n", path); >> 193 if (check_permission(path) != 0) { >> 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); >> 195 print_debug("check permission failed for %s\n", path); >> 196 file_close(fd); >> 197 fd = -1; >> 198 } >> 199 return fd; >> 200 } >> 201 >> 202 /* create attach file for given process */ >> 203 static int create_attach_file(pid_t pid) { >> 204 char path[PATH_MAX + 1]; >> 205 int fd; >> 206 fill_attach_file_name(path, sizeof(path), pid); >> 207 fd = file_open(path, O_CREAT | O_RDWR); >> 208 if (fd < 0) { >> 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); >> 210 print_debug("cannot create file %s\n", path); >> 211 } else { >> 212 print_debug("created attach file %s\n", path); >> 213 } >> 214 return fd; >> 215 } >> >> The following block of code only creates the .java_pid socket in the >> directory named by os::get_temp_directory(). On BSD, that function >> is hardcoded to return "/tmp". On MacOS X, that function returns >> the path of the "secure per-user temporary directory" if one is >> configured or "/tmp" if one is not. >> >> src/os/bsd/vm/attachListener_bsd.cpp >> >> 170 // Initialization - create a listener socket and bind it to a file >> 171 >> 172 int BsdAttachListener::init() { >> 173 char path[UNIX_PATH_MAX]; // socket file >> 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup >> 175 int listener; // listener socket (file descriptor >> ) >> 176 >> 177 // register function to cleanup >> 178 ::atexit(listener_cleanup); >> 179 >> 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", >> 181 os::get_temp_directory(), os::current_process_id()); >> 182 if (n < (int)UNIX_PATH_MAX) { >> 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); >> 184 } >> 185 if (n >= (int)UNIX_PATH_MAX) { >> 186 return -1; >> 187 } >> >> This block of code checks the process' current directory for an >> .attach_pid >> file before it checks os::get_temp_directory(). However, that check is >> just to see if the attach mechanism should be started. If it does get >> spoofed, there is little harm. >> >> 476 // If the file .attach_pid exists in the working directory >> 477 // or /tmp then this is the trigger to start the attach mechanism >> 478 bool AttachListener::is_init_trigger() { >> 479 if (init_at_startup() || is_initialized()) { >> 480 return false; // initialized at startup or already ini >> tialized >> 481 } >> 482 char path[PATH_MAX + 1]; >> 483 int ret; >> 484 struct stat st; >> 485 >> 486 snprintf(path, PATH_MAX + 1, "%s/.attach_pid%d", >> 487 os::get_temp_directory(), os::current_process_id()); >> 488 RESTARTABLE(::stat(path, &st), ret); >> 489 if (ret == 0) { >> 490 // simple check to avoid starting the attach mechanism when >> 491 // a bogus user creates the file >> 492 if (st.st_uid == geteuid()) { >> 493 init(); >> 494 return true; >> 495 } >> 496 } >> 497 return false; >> 498 } >> >> >> >> On 1/31/12 7:32 AM, Daniel D. Daugherty wrote: >>> Sorry, sent that last one as "reply to list" instead of "reply to >>> all"... >>> >>> I think you need to hold up on this one. I don't think the >>> assumption that .java_pid and .attach_pid files are always >>> in /tmp is a good one. >>> >>> More in a little bit. >>> >>> Dan >>> >>> On 1/31/12 1:10 AM, Staffan Larsen wrote: >>>> Moving "/tmp" to a static field, made it easier to write a comment >>>> explaining the rationale as well. >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 31 jan 2012, at 01:23, David Holmes wrote: >>>> >>>>> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>>>>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>>>>> 2. If you decide to hardcode "/tmp" please, create a global >>>>>>>> constant >>>>>>>> for it. >>>>>>> >>>>>>> I don't agree that this would make the code easier to read or >>>>>>> maintain. >>>>>>> I should, however, include a comment saying that the file is >>>>>>> always in >>>>>>> /tmp regardless of the value of java.io.tmpdir. >>>>> >>>>> Staffan: I still think changing the static field tmpdir to refer to >>>>> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >>>>> >>>>>> /tmp is common but not mandatory, especially if we speak about >>>>>> embedded >>>>>> systems. >>>>> >>>>> Dmitry: The point is that the VM will always put the file in /tmp. >>>>> That's wrong but the issue here is making the management Java code >>>>> match the hotspot code. >>>>> >>>>>> Native code should use P_tmpdir constant from stdio.h rather than >>>>>> hardcode "/tmp". >>>>>> >>>>>> As we can't access it from java I recommend to create a global >>>>>> constant >>>>>> somewhere to reduce possible future porting efforts. >>>>>> >>>>>> >>>>>>> Changing the tmpdir static would be a smaller fix, but all the cwd >>>>>>> code >>>>>>> would then remain. Yes, HotSpot never writes to cwd. >>>>>> >>>>>> I agree with Staffan, that looks for socket/door in cwd should be >>>>>> removed. >>>>> >>>>> Ok, if it is never needed then remove it. >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>> From kumar.x.srinivasan at oracle.com Thu Feb 2 15:39:04 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 02 Feb 2012 23:39:04 +0000 Subject: hg: jdk8/tl/jdk: 7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file Message-ID: <20120202233921.C8DF147321@hg.openjdk.java.net> Changeset: 24478d62d068 Author: ksrini Date: 2012-02-02 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24478d62d068 7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file Reviewed-by: ksrini, darcy Contributed-by: sonali.goel at oracle.com ! test/tools/launcher/Arrrghs.java + test/tools/launcher/MainClassAttributeTest.java From john.coomes at oracle.com Thu Feb 2 21:00:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:00:07 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b24 for changeset 1a5f1d6b98d6 Message-ID: <20120203050007.E63104733F@hg.openjdk.java.net> Changeset: 5350cd6e0cc0 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/5350cd6e0cc0 Added tag jdk8-b24 for changeset 1a5f1d6b98d6 ! .hgtags From john.coomes at oracle.com Thu Feb 2 21:00:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:00:14 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b24 for changeset b98f0e6dddf9 Message-ID: <20120203050016.A733E47340@hg.openjdk.java.net> Changeset: e45d6b406d5f Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/e45d6b406d5f Added tag jdk8-b24 for changeset b98f0e6dddf9 ! .hgtags From john.coomes at oracle.com Thu Feb 2 21:00:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:00:23 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b24 for changeset 7836655e2495 Message-ID: <20120203050023.443A747341@hg.openjdk.java.net> Changeset: bb694c151fc7 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bb694c151fc7 Added tag jdk8-b24 for changeset 7836655e2495 ! .hgtags From john.coomes at oracle.com Thu Feb 2 21:00:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:00:30 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b24 for changeset e0d90803439b Message-ID: <20120203050030.D3C5147342@hg.openjdk.java.net> Changeset: b376d901e006 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b376d901e006 Added tag jdk8-b24 for changeset e0d90803439b ! .hgtags From john.coomes at oracle.com Thu Feb 2 21:00:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:00:39 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b24 for changeset 34029a0c69bb Message-ID: <20120203050117.33B4447343@hg.openjdk.java.net> Changeset: 8da468cf037b Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8da468cf037b Added tag jdk8-b24 for changeset 34029a0c69bb ! .hgtags From john.coomes at oracle.com Thu Feb 2 21:02:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 05:02:38 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b24 for changeset 6c9d21ca92c4 Message-ID: <20120203050244.C2B1547344@hg.openjdk.java.net> Changeset: 5a784dab75f1 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5a784dab75f1 Added tag jdk8-b24 for changeset 6c9d21ca92c4 ! .hgtags From paul.hohensee at oracle.com Fri Feb 3 22:28:32 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Sat, 04 Feb 2012 06:28:32 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7142586: Cannot build on Solaris 11 due to use of ia_nice Message-ID: <20120204062837.3B20A47368@hg.openjdk.java.net> Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp From chris.hegarty at oracle.com Sat Feb 4 04:05:55 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 04 Feb 2012 12:05:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120204120631.896834736E@hg.openjdk.java.net> Changeset: bbadb6605a1c Author: chegar Date: 2012-02-04 07:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbadb6605a1c 7041778: Move SCTP implementation out of sun.nio.ch and into its own package Reviewed-by: alanb ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Net.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java + src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java + src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java + src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java + src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java + src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java + src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java + src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SctpNet.java + src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java + src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java + src/solaris/classes/sun/nio/ch/sctp/SendFailed.java + src/solaris/classes/sun/nio/ch/sctp/Shutdown.java - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c + src/solaris/native/sun/nio/ch/sctp/Sctp.h + src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c + src/solaris/native/sun/nio/ch/sctp/SctpNet.c + src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java Changeset: e528a64dd21b Author: chegar Date: 2012-02-04 07:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e528a64dd21b Merge From alan.bateman at oracle.com Sun Feb 5 04:32:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2012 12:32:02 +0000 Subject: hg: jdk8/tl/jaxws: 7140918: Remove dependency on apt and com.sun.mirror API Message-ID: <20120205123202.B14F64737E@hg.openjdk.java.net> Changeset: 6a8f54fb5f15 Author: alanb Date: 2012-02-05 12:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6a8f54fb5f15 7140918: Remove dependency on apt and com.sun.mirror API Reviewed-by: darcy Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com ! build-defs.xml ! jaxws.properties From alan.bateman at oracle.com Sun Feb 5 04:32:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 05 Feb 2012 12:32:51 +0000 Subject: hg: jdk8/tl/jdk: 7140918: Remove dependency on apt and com.sun.mirror API Message-ID: <20120205123319.F18E54737F@hg.openjdk.java.net> Changeset: ce5ffdb2be25 Author: alanb Date: 2012-02-05 12:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce5ffdb2be25 7140918: Remove dependency on apt and com.sun.mirror API Reviewed-by: darcy Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com ! make/common/Release.gmk ! make/common/internal/Defs-jaxws.gmk From david.holmes at oracle.com Sun Feb 5 19:31:30 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 06 Feb 2012 03:31:30 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7132779: build-infra merge: Enable ccache to work for most developer builds. Message-ID: <20120206033135.85A6A47386@hg.openjdk.java.net> Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp From joe.darcy at oracle.com Sun Feb 5 21:50:37 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 Feb 2012 05:50:37 +0000 Subject: hg: jdk8/tl/jdk: 7041249: Remove apt tool and API from the JDK Message-ID: <20120206055055.1861847389@hg.openjdk.java.net> Changeset: e55522710586 Author: darcy Date: 2012-02-05 21:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e55522710586 7041249: Remove apt tool and API from the JDK Reviewed-by: jjg, ohair ! make/com/sun/Makefile ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/launchers/Makefile ! make/launchers/Makefile.launcher - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 From joe.darcy at oracle.com Sun Feb 5 22:00:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 06 Feb 2012 06:00:02 +0000 Subject: hg: jdk8/tl/langtools: 7041249: Remove apt tool and API from the JDK Message-ID: <20120206060007.1C28F4738A@hg.openjdk.java.net> Changeset: 2360c8213989 Author: darcy Date: 2012-02-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2360c8213989 7041249: Remove apt tool and API from the JDK Reviewed-by: jjg, ohair ! make/Makefile-classic ! make/build.properties ! make/build.xml ! make/netbeans/README - make/test/lib/apt.sh ! make/test/lib/src.gold.txt - src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java - src/share/classes/com/sun/mirror/apt/Filer.java - src/share/classes/com/sun/mirror/apt/Messager.java - src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java - src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java - src/share/classes/com/sun/mirror/apt/RoundState.java - src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationValue.java - src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java - src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java - src/share/classes/com/sun/mirror/declaration/Declaration.java - src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java - src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java - src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java - src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java - src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java - src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java - src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java - src/share/classes/com/sun/mirror/declaration/Modifier.java - src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java - src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/overview.html - src/share/classes/com/sun/mirror/type/AnnotationType.java - src/share/classes/com/sun/mirror/type/ArrayType.java - src/share/classes/com/sun/mirror/type/ClassType.java - src/share/classes/com/sun/mirror/type/DeclaredType.java - src/share/classes/com/sun/mirror/type/EnumType.java - src/share/classes/com/sun/mirror/type/InterfaceType.java - src/share/classes/com/sun/mirror/type/MirroredTypeException.java - src/share/classes/com/sun/mirror/type/MirroredTypesException.java - src/share/classes/com/sun/mirror/type/PrimitiveType.java - src/share/classes/com/sun/mirror/type/ReferenceType.java - src/share/classes/com/sun/mirror/type/TypeMirror.java - src/share/classes/com/sun/mirror/type/TypeVariable.java - src/share/classes/com/sun/mirror/type/VoidType.java - src/share/classes/com/sun/mirror/type/WildcardType.java - src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/util/DeclarationFilter.java - src/share/classes/com/sun/mirror/util/DeclarationScanner.java - src/share/classes/com/sun/mirror/util/DeclarationVisitor.java - src/share/classes/com/sun/mirror/util/DeclarationVisitors.java - src/share/classes/com/sun/mirror/util/Declarations.java - src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java - src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java - src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java - src/share/classes/com/sun/mirror/util/SourcePosition.java - src/share/classes/com/sun/mirror/util/TypeVisitor.java - src/share/classes/com/sun/mirror/util/Types.java - src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/tools/apt/Main.java - src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java - src/share/classes/com/sun/tools/apt/comp/Apt.java - src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java - src/share/classes/com/sun/tools/apt/comp/PrintAP.java - src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java - src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/CommandLine.java - src/share/classes/com/sun/tools/apt/main/Main.java - src/share/classes/com/sun/tools/apt/mirror/AptEnv.java - src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java - src/share/classes/com/sun/tools/apt/resources/apt.properties - src/share/classes/com/sun/tools/apt/resources/apt_ja.properties - src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties - src/share/classes/com/sun/tools/apt/util/Bark.java - test/tools/apt/Basics/Aggregate.java - test/tools/apt/Basics/ClassAnnotations.java - test/tools/apt/Basics/FreshnessApf.java - test/tools/apt/Basics/GenClass.java - test/tools/apt/Basics/Indirect.java - test/tools/apt/Basics/Lacuna.java - test/tools/apt/Basics/MethodAnnotations.java - test/tools/apt/Basics/Milk.java - test/tools/apt/Basics/MisMatch.java - test/tools/apt/Basics/Misc.java - test/tools/apt/Basics/MyMarker.java - test/tools/apt/Basics/MySimple.java - test/tools/apt/Basics/NestedClassAnnotations.java - test/tools/apt/Basics/ParameterAnnotations.java - test/tools/apt/Basics/StaticFieldAnnotations.java - test/tools/apt/Basics/StaticMethodAnnotations.java - test/tools/apt/Basics/TestGetPackageApf.java - test/tools/apt/Basics/TestGetTypeDeclarationApf.java - test/tools/apt/Basics/annot/AnnotMarker.java - test/tools/apt/Basics/annot/AnnotShangri_la.java - test/tools/apt/Basics/annot/AnnotSimple.java - test/tools/apt/Basics/annot/annot2/AnnotMarker2.java - test/tools/apt/Basics/annot/annot2/AnnotSimple2.java ! test/tools/apt/Basics/apt.sh - test/tools/apt/Basics/com.sun.mirror.apt.AnnotationProcessorFactory - test/tools/apt/Basics/foo/bar/Baz.java - test/tools/apt/Basics/foo/bar/Quux.java - test/tools/apt/Basics/golden.txt - test/tools/apt/Basics/goldenAggregate.txt - test/tools/apt/Basics/p1/p2.java - test/tools/apt/Basics/p1/p2/C1.java - test/tools/apt/Basics/print.sh - test/tools/apt/Compile/ClassDeclApf.java - test/tools/apt/Compile/ClassDeclApf2.java - test/tools/apt/Compile/Dummy1.java - test/tools/apt/Compile/ErrorAPF.java - test/tools/apt/Compile/HelloAnnotation.java - test/tools/apt/Compile/HelloWorld.java - test/tools/apt/Compile/Round1Apf.java - test/tools/apt/Compile/Round2Apf.java - test/tools/apt/Compile/Round3Apf.java - test/tools/apt/Compile/Round4Apf.java - test/tools/apt/Compile/Rounds.java - test/tools/apt/Compile/StaticApf.java - test/tools/apt/Compile/WarnAPF.java - test/tools/apt/Compile/WrappedStaticApf.java - test/tools/apt/Compile/compile.sh - test/tools/apt/Compile/golden.txt - test/tools/apt/Compile/goldenFactory.txt - test/tools/apt/Compile/goldenWarn.txt - test/tools/apt/Compile/servicesRound1 - test/tools/apt/Compile/servicesRound2 - test/tools/apt/Compile/servicesRound3 - test/tools/apt/Compile/servicesRound4 - test/tools/apt/Compile/servicesStaticApf - test/tools/apt/Compile/src/AhOneClass.java - test/tools/apt/Compile/src/AndAhTwoClass.java - test/tools/apt/Compile/src/Round1Class.java - test/tools/apt/Discovery/Dee.java - test/tools/apt/Discovery/Dum.java - test/tools/apt/Discovery/Empty.java - test/tools/apt/Discovery/PhantomTouch.java - test/tools/apt/Discovery/PhantomUpdate.java - test/tools/apt/Discovery/Touch.java - test/tools/apt/Discovery/discovery.sh - test/tools/apt/Discovery/servicesBadTouch - test/tools/apt/Discovery/servicesPhantomTouch - test/tools/apt/Discovery/servicesTouch - test/tools/apt/Discovery/servicesTweedle - test/tools/apt/Misc/Marked.java - test/tools/apt/Misc/Marker.java - test/tools/apt/Misc/Misc.java - test/tools/apt/Misc/misc.sh - test/tools/apt/Misc/servicesMisc - test/tools/apt/Options/Marked.java - test/tools/apt/Options/Marker.java - test/tools/apt/Options/OptionChecker.java - test/tools/apt/Options/options.sh - test/tools/apt/Options/servicesOptions - test/tools/apt/Scanners/Counter.java - test/tools/apt/Scanners/MemberOrderApf.java - test/tools/apt/Scanners/Order.java - test/tools/apt/Scanners/Scanner.java - test/tools/apt/Scanners/TestEnum.java - test/tools/apt/Scanners/VisitOrder.java - test/tools/apt/Scanners/scanner.sh - test/tools/apt/Scanners/servicesScanner - test/tools/apt/lib/Ignore.java - test/tools/apt/lib/Test.java - test/tools/apt/lib/TestProcessor.java - test/tools/apt/lib/TestProcessorFactory.java - test/tools/apt/lib/Tester.java - test/tools/apt/mirror/declaration/AnnoMirror.java - test/tools/apt/mirror/declaration/AnnoTypeDecl.java - test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java - test/tools/apt/mirror/declaration/AnnoVal.java - test/tools/apt/mirror/declaration/ClassDecl.java - test/tools/apt/mirror/declaration/ConstExpr.java - test/tools/apt/mirror/declaration/ConstructorDecl.java - test/tools/apt/mirror/declaration/EnumDecl.java - test/tools/apt/mirror/declaration/FieldDecl.java - test/tools/apt/mirror/declaration/GetAnno.java - test/tools/apt/mirror/declaration/InterfaceDecl.java - test/tools/apt/mirror/declaration/MethodDecl.java - test/tools/apt/mirror/declaration/PackageDecl.java - test/tools/apt/mirror/declaration/ParameterDecl.java - test/tools/apt/mirror/declaration/pkg1/AClass.java - test/tools/apt/mirror/declaration/pkg1/AnAnnoType.java - test/tools/apt/mirror/declaration/pkg1/AnEnum.java - test/tools/apt/mirror/declaration/pkg1/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/package-info.java - test/tools/apt/mirror/declaration/pkg1/pkg2/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/pkg2/package.html - test/tools/apt/mirror/type/AnnoTyp.java - test/tools/apt/mirror/type/ArrayTyp.java - test/tools/apt/mirror/type/ClassTyp.java - test/tools/apt/mirror/type/EnumTyp.java - test/tools/apt/mirror/type/InterfaceTyp.java - test/tools/apt/mirror/type/PrimitiveTyp.java - test/tools/apt/mirror/type/TypeVar.java - test/tools/apt/mirror/type/WildcardTyp.java - test/tools/apt/mirror/util/Overrides.java - test/tools/apt/mirror/util/TypeCreation.java From david.holmes at oracle.com Mon Feb 6 18:55:13 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 07 Feb 2012 02:55:13 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Message-ID: <20120207025517.43DA9473B1@hg.openjdk.java.net> Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make From alan.bateman at oracle.com Tue Feb 7 05:28:48 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Feb 2012 13:28:48 +0000 Subject: hg: jdk8/tl/jdk: 7142847: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java has incorrect @run tag, runs Basic Message-ID: <20120207132908.58363473BC@hg.openjdk.java.net> Changeset: c6d6ef8ec2bf Author: alanb Date: 2012-02-07 13:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6d6ef8ec2bf 7142847: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java has incorrect @run tag, runs Basic Reviewed-by: chegar ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java From frederic.parain at oracle.com Tue Feb 7 15:40:10 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 07 Feb 2012 23:40:10 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 55 new changesets Message-ID: <20120207234201.D5322473D0@hg.openjdk.java.net> Changeset: 53a127075045 Author: kvn Date: 2012-01-20 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/53a127075045 7131302: connode.cpp:205 Error: ShouldNotReachHere() Summary: Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Reviewed-by: jrose ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 9164b8236699 Author: iveresov Date: 2012-01-20 15:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9164b8236699 7131028: Switch statement takes wrong path Summary: Pass correct type to branch in LIRGenerator::do_SwitchRanges() Reviewed-by: kvn, never ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: a81f60ddab06 Author: never Date: 2012-01-22 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a81f60ddab06 7130676: Tiered: assert(bci == 0 || 0<= bci && bciis_loaded() Summary: handle not loaded array klass in Parse::do_checkcast(). Reviewed-by: kvn, never ! src/share/vm/opto/parseHelper.cpp Changeset: 5dbed2f542ff Author: bdelsart Date: 2012-01-26 16:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5dbed2f542ff 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Summary: improvements of TraceMethodHandles for JSR292 Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 20334ed5ed3c Author: iveresov Date: 2012-01-26 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/20334ed5ed3c 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Summary: Make sure that CompilationPolicy::event() doesn't throw exceptions Reviewed-by: kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 072384a61312 Author: jrose Date: 2012-01-26 19:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/072384a61312 Merge Changeset: 2e966d967c5c Author: johnc Date: 2012-01-13 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e966d967c5c 7121547: G1: High number mispredicted branches while iterating over the marking bitmap Summary: There is a high number of mispredicted branches associated with calling BitMap::iteratate() from within CMBitMapRO::iterate(). Implement a version of CMBitMapRO::iterate() directly using inline-able routines. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 851b58c26def Author: brutisso Date: 2012-01-16 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/851b58c26def 7130334: G1: Change comments and error messages that refer to CMS in g1/concurrentMark.cpp/hpp Summary: Removed references to CMS in the concurrentMark.cpp/hpp files. Reviewed-by: tonyp, jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 9509c20bba28 Author: brutisso Date: 2012-01-16 22:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9509c20bba28 6976060: G1: humongous object allocations should initiate marking cycles when necessary Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 0b3d1ec6eaee Author: tonyp Date: 2012-01-18 10:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0b3d1ec6eaee 7097586: G1: improve the per-space output when using jmap -heap Summary: Extend the jmap -heap output for G1 to include some more G1-specific information. Reviewed-by: brutisso, johnc, poonam ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSetBase.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: 7ca7be5a6a0b Author: johnc Date: 2012-01-17 10:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ca7be5a6a0b 7129271: G1: Interference from multiple threads in PrintGC/PrintGCDetails output Summary: During an initial mark pause, signal the Concurrent Mark thread after the pause output from PrintGC/PrintGCDetails is complete. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: a8a126788ea0 Author: tonyp Date: 2012-01-19 09:13 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a8a126788ea0 7078465: G1: Don't use the undefined value (-1) for the G1 old memory pool max size Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 57025542827f Author: brutisso Date: 2012-01-20 18:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/57025542827f 7131791: G1: Asserts in nightly testing due to 6976060 Summary: Create a handle and fake an object to make sure that we don't loose the memory we just allocated Reviewed-by: tonyp, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6a78aa6ac1ff Author: brutisso Date: 2012-01-23 20:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6a78aa6ac1ff 7132311: G1: assert((s == klass->oop_size(this)) || (Universe::heap()->is_gc_active() && ((is_typeArray()... Summary: Move the check for when to call collect() to before we do a humongous object allocation Reviewed-by: stefank, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 877914d90c57 Author: tonyp Date: 2012-01-24 17:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/877914d90c57 7132398: G1: java.lang.IllegalArgumentException: Invalid threshold: 9223372036854775807 > max (1073741824) Summary: Was not passing the right old pool max to the memory pool constructor in the fix for 7078465. Reviewed-by: brutisso, johnc ! src/share/vm/services/g1MemoryPool.cpp Changeset: d30fa85f9994 Author: johnc Date: 2012-01-12 00:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d30fa85f9994 6484965: G1: piggy-back liveness accounting phase on marking Summary: Remove the separate counting phase of concurrent marking by tracking the amount of marked bytes and the cards spanned by marked objects in marking task/worker thread local data structures, which are updated as individual objects are marked. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: eff609af17d7 Author: tonyp Date: 2012-01-25 12:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eff609af17d7 7127706: G1: re-enable survivors during the initial-mark pause Summary: Re-enable survivors during the initial-mark pause. Afterwards, the concurrent marking threads have to scan them and mark everything reachable from them. The next GC will have to wait for the survivors to be scanned. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a5244e07b761 Author: jcoomes Date: 2012-01-25 21:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a5244e07b761 7112413: JVM Crash, possibly GC-related Summary: disable UseAdaptiveSizePolicy with the CMS and ParNew Reviewed-by: johnc, brutisso ! src/share/vm/runtime/arguments.cpp Changeset: b4ebad3520bb Author: johnc Date: 2012-01-26 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4ebad3520bb 7133038: G1: Some small profile based optimizations Summary: Some minor profile based optimizations. Reduce the number of branches and branch mispredicts by removing some virtual calls, through closure specalization, and refactoring some conditional statements. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 0a10d80352d5 Author: brutisso Date: 2012-01-27 09:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0a10d80352d5 Merge - src/os/bsd/vm/decoder_bsd.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: bf5da1648543 Author: kamg Date: 2012-01-27 10:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf5da1648543 Merge ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp Changeset: 6edfe6e42a68 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags Changeset: 9e177d44b10f Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9e177d44b10f Merge Changeset: a80fd4f45d7a Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a80fd4f45d7a Added tag hs23-b12 for changeset 9e177d44b10f ! .hgtags Changeset: 9f1c2b7cdfb6 Author: amurillo Date: 2012-01-27 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9f1c2b7cdfb6 7135385: new hotspot build - hs23-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: be649fefcdc2 Author: stefank Date: 2012-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/be649fefcdc2 7134655: Crash in reference processing when doing single-threaded remarking Summary: Temporarily disabled multi-threaded reference discovery when entering a single-threaded remark phase. Reviewed-by: brutisso, tonyp, jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c03e06373b47 Author: stefank Date: 2012-01-28 01:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c03e06373b47 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: 2eeebe4b4213 Author: brutisso Date: 2012-01-30 15:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2eeebe4b4213 7140909: Visual Studio project builds broken: need to define INCLUDE_TRACE Summary: Add define of INCLUDE_TRACE Reviewed-by: sla, kamg ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ab44ceb4d57 Merge Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ea677dbdd883 Merge From joe.darcy at oracle.com Tue Feb 7 17:40:05 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 08 Feb 2012 01:40:05 +0000 Subject: hg: jdk8/tl/jdk: 7143629: JDK jar/zip code should use unsigned library support Message-ID: <20120208014023.43199473D2@hg.openjdk.java.net> Changeset: 946056e6116e Author: darcy Date: 2012-02-07 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/946056e6116e 7143629: JDK jar/zip code should use unsigned library support Reviewed-by: sherman ! src/share/classes/java/util/jar/JarOutputStream.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java From weijun.wang at oracle.com Tue Feb 7 19:45:21 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 08 Feb 2012 03:45:21 +0000 Subject: hg: jdk8/tl/jdk: 6880619: reg tests for 6879540 Message-ID: <20120208034540.77D12473DC@hg.openjdk.java.net> Changeset: 085c4f780d4e Author: weijun Date: 2012-02-08 11:44 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/085c4f780d4e 6880619: reg tests for 6879540 Reviewed-by: valeriep + test/sun/security/krb5/auto/EmptyPassword.java From chris.hegarty at oracle.com Wed Feb 8 03:20:44 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 08 Feb 2012 11:20:44 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120208112123.3591B473E4@hg.openjdk.java.net> Changeset: c64c815974ff Author: chegar Date: 2012-02-08 11:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c64c815974ff 7105929: java/util/concurrent/FutureTask/BlockingTaskExecutor.java fails on solaris sparc Reviewed-by: dholmes ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java Changeset: 7289599216fe Author: gadams Date: 2012-02-08 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7289599216fe 6736316: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient Reviewed-by: chegar, dholmes, alanb ! test/java/util/concurrent/locks/Lock/FlakyMutex.java Changeset: 72d8f91514d1 Author: gadams Date: 2012-02-08 11:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d8f91514d1 6957683: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing Reviewed-by: chegar, dholmes, alanb ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java From poonam.bajaj at oracle.com Wed Feb 8 20:41:26 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 09 Feb 2012 10:11:26 +0530 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB Message-ID: <4F334E76.9030406@oracle.com> Could I have code reviews for the following fix: 7009098: SA cannot open core file larger than 2GB http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ Serviceability Agent on Linux is not able to open core files larger than 2GB. The fix is to enable the 'Large File Support' by compiling the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both agent/src/os/linux/Makefile (which builds SA from agent/make/) and make/linux/makefiles/saproc.make (which builds SA with Hotspot build). There is one more change with which SA should first load libraries from the path specified with SA_ALTROOT rather than loading from the host system. Thanks, Poonam -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120209/d473e0bd/attachment.html From rednaxelafx at gmail.com Wed Feb 8 21:20:15 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 9 Feb 2012 13:20:15 +0800 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: <4F334E76.9030406@oracle.com> References: <4F334E76.9030406@oracle.com> Message-ID: Hi Poonam, Could the synopsis include the fact that this only affects Linux/x86 32-bit? I got a bit confused when I first read the synopsis, because I've been using SA to open core files around 4GB~5GB on Linux/x64 routinely, and it worked. Regards, Kris Mok On Thu, Feb 9, 2012 at 12:41 PM, Poonam Bajaj wrote: > Could I have code reviews for the following fix: > > 7009098: SA cannot open core file larger than 2GB > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 > Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ > > Serviceability Agent on Linux is not able to open core files larger > than 2GB. The fix is to enable the 'Large File Support' by compiling > the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both > agent/src/os/linux/Makefile (which builds SA from agent/make/) and > make/linux/makefiles/saproc.make (which builds SA with Hotspot build). > > There is one more change with which SA should first load libraries > from the path specified with SA_ALTROOT rather than loading from > the host system. > > > Thanks, > Poonam > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120209/e7b97367/attachment.html From poonam.bajaj at oracle.com Wed Feb 8 21:26:58 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 09 Feb 2012 10:56:58 +0530 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: References: <4F334E76.9030406@oracle.com> Message-ID: <4F335922.3020008@oracle.com> Yes, I will change the synopsis of the bug to make it clear that this only affects Linux 32bit. Thanks, Poonam On 2/9/2012 10:50 AM, Krystal Mok wrote: > Hi Poonam, > > Could the synopsis include the fact that this only affects Linux/x86 > 32-bit? > I got a bit confused when I first read the synopsis, because I've been > using SA to open core files around 4GB~5GB on Linux/x64 routinely, and > it worked. > > Regards, > Kris Mok > > On Thu, Feb 9, 2012 at 12:41 PM, Poonam Bajaj > wrote: > > Could I have code reviews for the following fix: > > 7009098: SA cannot open core file larger than 2GB > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 > > Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ > > > Serviceability Agent on Linux is not able to open core files larger > than 2GB. The fix is to enable the 'Large File Support' by compiling > the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both > agent/src/os/linux/Makefile (which builds SA from agent/make/) and > make/linux/makefiles/saproc.make (which builds SA with Hotspot > build). > > There is one more change with which SA should first load libraries > from the path specified with SA_ALTROOT rather than loading from > the host system. > > > Thanks, > Poonam > -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120209/b2801a13/attachment.html From david.holmes at oracle.com Wed Feb 8 22:06:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Feb 2012 16:06:45 +1000 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: <4F334E76.9030406@oracle.com> References: <4F334E76.9030406@oracle.com> Message-ID: <4F336275.7090101@oracle.com> On 9/02/2012 2:41 PM, Poonam Bajaj wrote: > Could I have code reviews for the following fix: > > 7009098: SA cannot open core file larger than 2GB > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 > Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ > > Serviceability Agent on Linux is not able to open core files larger > than 2GB. The fix is to enable the 'Large File Support' by compiling > the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both > agent/src/os/linux/Makefile (which builds SA from agent/make/) and > make/linux/makefiles/saproc.make (which builds SA with Hotspot build). This seems ok. > There is one more change with which SA should first load libraries > from the path specified with SA_ALTROOT rather than loading from > the host system. Where does this come from? It is not related to this CR. Is there another CR indicating the current behaviour is incorrect? Or a spec for it that indicates it is incorrect? David ----- > > Thanks, > Poonam > -- > > From poonam.bajaj at oracle.com Wed Feb 8 22:42:20 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 09 Feb 2012 12:12:20 +0530 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: <4F336275.7090101@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> Message-ID: <4F336ACC.6070106@oracle.com> Hi David, On 2/9/2012 11:36 AM, David Holmes wrote: > On 9/02/2012 2:41 PM, Poonam Bajaj wrote: >> Could I have code reviews for the following fix: >> >> 7009098: SA cannot open core file larger than 2GB >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 >> Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ >> >> Serviceability Agent on Linux is not able to open core files larger >> than 2GB. The fix is to enable the 'Large File Support' by compiling >> the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both >> agent/src/os/linux/Makefile (which builds SA from agent/make/) and >> make/linux/makefiles/saproc.make (which builds SA with Hotspot build). > > This seems ok. > >> There is one more change with which SA should first load libraries >> from the path specified with SA_ALTROOT rather than loading from >> the host system. > > Where does this come from? It is not related to this CR. Is there > another CR indicating the current behaviour is incorrect? Or a spec > for it that indicates it is incorrect? > This change became necessary to open the same customer provided core which required the first change. There is no separate bug filed for this change. There is a document in the hotspot repository hotspot/agent/doc/transported_core.html which talks about the transported cores and the use of SA_ALTROOT. " The best possible way to debug a transported core dump is to match the debugger machine to that of core dump machine. i.e., have same Kernel and libthread patch level between the machines. mdb (Solaris modular debugger) may be used to find the Kernel patch level of core dump machine and debugger machine may be brought to the same level. If the matching machine is "far off" in your network, then * consider using rlogin and CLHSDB - SA command line HSDB interface or * use SA remote debugging and debug the core from core machine remotely. But, it may not be feasible to find matching machine to debug. If so, you can copy all application shared objects (and libthread_db.so, if needed) from the core dump machine into your debugger machine's directory, say, /export/applibs. Now, set *SA_ALTROOT* environment variable to point to /export/applibs directory. Note that /export/applibs should either contain matching 'full path' of libraries. i.e., /usr/lib/libthread_db.so from core machine should be under /export/applibs/use/lib directory and /use/java/jre/lib/sparc/client/libjvm.so from core machine should be under /export/applibs/use/java/jre/lib/sparc/client so on or /export/applibs should just contain libthread_db.so, libjvm.so etc. directly. " " On Linux, SA parses core and shared library ELF files. SA *does not* use libthread_db.so or rtld_db.so for core dump debugging (although libthread_db.so is used for live process debugging). But, you may still face problems with transported core dumps, because matching shared objects may not be in the path(s) specified in core dump file. To workaround this, you can define environment variable *SA_ALTROOT* to be the directory where shared libraries are kept. The semantics of this env. variable is same as that for Solaris (please refer above)." So, if SA_ALTROOT is specified, libraries from this path should get loaded and not from the path embedded in the core file. Thanks, Poonam > David > ----- > >> >> Thanks, >> Poonam >> -- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120209/73c7dc39/attachment-0001.html From david.holmes at oracle.com Wed Feb 8 22:51:56 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Feb 2012 16:51:56 +1000 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: <4F336ACC.6070106@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> <4F336ACC.6070106@oracle.com> Message-ID: <4F336D0C.10005@oracle.com> Hi Poonam, On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>> There is one more change with which SA should first load libraries >>> from the path specified with SA_ALTROOT rather than loading from >>> the host system. >> >> Where does this come from? It is not related to this CR. Is there >> another CR indicating the current behaviour is incorrect? Or a spec >> for it that indicates it is incorrect? >> > This change became necessary to open the same customer provided core > which required the first change. There is no separate bug filed for this > change. Actually there is: 7009089 Thanks for all the info. Your change agrees with the proposed fix in 7009089, and it seems consist with how Solaris checks the alt-root path first. So this looks good to me. David ----- > > There is a document in the hotspot repository > hotspot/agent/doc/transported_core.html which talks about the > transported cores and the use of SA_ALTROOT. > > " The best possible way to debug a transported core dump is to match the > debugger machine to that of core dump machine. i.e., have same Kernel > and libthread patch level between the machines. mdb (Solaris modular > debugger) may be used to find the Kernel patch level of core dump > machine and debugger machine may be brought to the same level. > > If the matching machine is "far off" in your network, then > > * consider using rlogin and CLHSDB - SA command line HSDB interface > > or > * use SA remote debugging and debug the core from core machine remotely. > > But, it may not be feasible to find matching machine to debug. If so, > you can copy all application shared objects (and libthread_db.so, if > needed) from the core dump machine into your debugger machine's > directory, say, /export/applibs. Now, set *SA_ALTROOT* environment > variable to point to /export/applibs directory. Note that > /export/applibs should either contain matching 'full path' of libraries. > i.e., /usr/lib/libthread_db.so from core machine should be under > /export/applibs/use/lib directory and > /use/java/jre/lib/sparc/client/libjvm.so from core machine should be > under /export/applibs/use/java/jre/lib/sparc/client so on or > /export/applibs should just contain libthread_db.so, libjvm.so etc. > directly. " > > " On Linux, SA parses core and shared library ELF files. SA *does not* > use libthread_db.so or rtld_db.so for core dump debugging (although > libthread_db.so is used for live process debugging). But, you may still > face problems with transported core dumps, because matching shared > objects may not be in the path(s) specified in core dump file. To > workaround this, you can define environment variable *SA_ALTROOT* to be > the directory where shared libraries are kept. The semantics of this > env. variable is same as that for Solaris (please refer above)." > > So, if SA_ALTROOT is specified, libraries from this path should get > loaded and not from the path embedded in the core file. > > > Thanks, > Poonam > > >> David >> ----- >> >>> >>> Thanks, >>> Poonam >>> -- >>> >>> From poonam.bajaj at oracle.com Wed Feb 8 22:59:19 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 09 Feb 2012 12:29:19 +0530 Subject: Review Request: 7009098: SA cannot open core file larger than 2GB In-Reply-To: <4F336D0C.10005@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> <4F336ACC.6070106@oracle.com> <4F336D0C.10005@oracle.com> Message-ID: <4F336EC7.3000607@oracle.com> On 2/9/2012 12:21 PM, David Holmes wrote: > Hi Poonam, > > On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>>> There is one more change with which SA should first load libraries >>>> from the path specified with SA_ALTROOT rather than loading from >>>> the host system. >>> >>> Where does this come from? It is not related to this CR. Is there >>> another CR indicating the current behaviour is incorrect? Or a spec >>> for it that indicates it is incorrect? >>> >> This change became necessary to open the same customer provided core >> which required the first change. There is no separate bug filed for this >> change. > > Actually there is: 7009089 > Thanks for finding this bug number. I will link both the bugs. > Thanks for all the info. Your change agrees with the proposed fix in > 7009089, and it seems consist with how Solaris checks the alt-root > path first. > > So this looks good to me. > Thanks, Poonam > David > ----- > > >> >> There is a document in the hotspot repository >> hotspot/agent/doc/transported_core.html which talks about the >> transported cores and the use of SA_ALTROOT. >> >> " The best possible way to debug a transported core dump is to match the >> debugger machine to that of core dump machine. i.e., have same Kernel >> and libthread patch level between the machines. mdb (Solaris modular >> debugger) may be used to find the Kernel patch level of core dump >> machine and debugger machine may be brought to the same level. >> >> If the matching machine is "far off" in your network, then >> >> * consider using rlogin and CLHSDB - SA command line HSDB interface >> >> or >> * use SA remote debugging and debug the core from core machine >> remotely. >> >> But, it may not be feasible to find matching machine to debug. If so, >> you can copy all application shared objects (and libthread_db.so, if >> needed) from the core dump machine into your debugger machine's >> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment >> variable to point to /export/applibs directory. Note that >> /export/applibs should either contain matching 'full path' of libraries. >> i.e., /usr/lib/libthread_db.so from core machine should be under >> /export/applibs/use/lib directory and >> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be >> under /export/applibs/use/java/jre/lib/sparc/client so on or >> /export/applibs should just contain libthread_db.so, libjvm.so etc. >> directly. " >> >> " On Linux, SA parses core and shared library ELF files. SA *does not* >> use libthread_db.so or rtld_db.so for core dump debugging (although >> libthread_db.so is used for live process debugging). But, you may still >> face problems with transported core dumps, because matching shared >> objects may not be in the path(s) specified in core dump file. To >> workaround this, you can define environment variable *SA_ALTROOT* to be >> the directory where shared libraries are kept. The semantics of this >> env. variable is same as that for Solaris (please refer above)." >> >> So, if SA_ALTROOT is specified, libraries from this path should get >> loaded and not from the path embedded in the core file. >> >> >> Thanks, >> Poonam >> >> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Poonam >>>> -- >>>> >>>> From yumin.qi at sun.com Thu Feb 9 01:59:47 2012 From: yumin.qi at sun.com (yumin.qi at sun.com) Date: Thu, 09 Feb 2012 09:59:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Message-ID: <20120209095950.4061C4740B@hg.openjdk.java.net> Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp From frederic.parain at oracle.com Thu Feb 9 05:38:04 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 09 Feb 2012 14:38:04 +0100 Subject: Request for Review (S) : 7140868 TEST_BUG: jcmd tests need to use -XX:+UsePerfData Message-ID: <4F33CC3C.40609@oracle.com> Here's a very simple fix which adds -J-XX:+UsePerfData to all jcmd test in order to pass with the embedded builds. The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140868 The Webrev: http://cr.openjdk.java.net/~fparain/7140868/webrev.00/ I've tested manually with embedded builds that adding -J-XX:+UsePerfData is sufficient to pass the tests. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From alan.bateman at oracle.com Thu Feb 9 05:45:50 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2012 13:45:50 +0000 Subject: hg: jdk8/tl/jdk: 7114611: (fs) DirectoryStream fails with SIGBUS on some embedded platforms, dirent alignment Message-ID: <20120209134626.6B1D94740E@hg.openjdk.java.net> Changeset: 184b9cb4f13a Author: alanb Date: 2012-02-09 13:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184b9cb4f13a 7114611: (fs) DirectoryStream fails with SIGBUS on some embedded platforms, dirent alignment Reviewed-by: dholmes, alanb Contributed-by: carlos.lucasius at oracle.com ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From alan.bateman at oracle.com Thu Feb 9 08:39:29 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 09 Feb 2012 16:39:29 +0000 Subject: hg: jdk8/tl/jdk: 7144086: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java failing intermittently Message-ID: <20120209163946.4821447413@hg.openjdk.java.net> Changeset: 8326d434681d Author: alanb Date: 2012-02-09 16:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8326d434681d 7144086: TEST_BUG: java/nio/file/WatchService/SensitivityModifier.java failing intermittently Reviewed-by: chegar ! test/java/nio/file/WatchService/SensitivityModifier.java From zhengyu.gu at oracle.com Thu Feb 9 11:01:11 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 09 Feb 2012 19:01:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120209190117.F152647417@hg.openjdk.java.net> Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ea527c5cde03 Merge From david.holmes at oracle.com Thu Feb 9 13:46:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Feb 2012 07:46:23 +1000 Subject: Request for Review (S) : 7140868 TEST_BUG: jcmd tests need to use -XX:+UsePerfData In-Reply-To: <4F33CC3C.40609@oracle.com> References: <4F33CC3C.40609@oracle.com> Message-ID: <4F343EAF.2040404@oracle.com> Hi Fred, On 9/02/2012 11:38 PM, Frederic Parain wrote: > Here's a very simple fix which adds -J-XX:+UsePerfData > to all jcmd test in order to pass with the embedded builds. Can't you redefine $JCMD to include the -J-XX:+UsePerfData so that it's needed in fewer places? Otherwise seems correct. David > The CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140868 > > The Webrev: > http://cr.openjdk.java.net/~fparain/7140868/webrev.00/ > > I've tested manually with embedded builds that adding > -J-XX:+UsePerfData is sufficient to pass the tests. > > Thanks, > > Fred > From weijun.wang at oracle.com Thu Feb 9 19:42:30 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 10 Feb 2012 03:42:30 +0000 Subject: hg: jdk8/tl/jdk: 6879539: enable empty password support for pkcs12 keystore Message-ID: <20120210034249.51BB64742A@hg.openjdk.java.net> Changeset: bdd1dd1e1462 Author: weijun Date: 2012-02-10 11:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdd1dd1e1462 6879539: enable empty password support for pkcs12 keystore Reviewed-by: vinnie, weijun Contributed-by: Florian Weimer ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/Bug6415637.java From john.coomes at oracle.com Thu Feb 9 21:00:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:00:39 +0000 Subject: hg: hsx/hotspot-rt: 4 new changesets Message-ID: <20120210050039.4587A4743D@hg.openjdk.java.net> Changeset: 0f653ee93477 Author: alanb Date: 2012-01-24 09:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0f653ee93477 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties Changeset: bd3fcc98c5d2 Author: lana Date: 2012-01-28 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/bd3fcc98c5d2 Merge Changeset: 221a378e06a3 Author: lana Date: 2012-02-07 10:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/221a378e06a3 Merge Changeset: 2accafff224a Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2accafff224a Added tag jdk8-b25 for changeset 221a378e06a3 ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:00:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:00:46 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b25 for changeset e45d6b406d5f Message-ID: <20120210050049.3CF054743E@hg.openjdk.java.net> Changeset: 79f709a099f4 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/79f709a099f4 Added tag jdk8-b25 for changeset e45d6b406d5f ! .hgtags From poonam.bajaj at oracle.com Thu Feb 9 21:00:52 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Fri, 10 Feb 2012 10:30:52 +0530 Subject: Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit In-Reply-To: <4F336EC7.3000607@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> <4F336ACC.6070106@oracle.com> <4F336D0C.10005@oracle.com> <4F336EC7.3000607@oracle.com> Message-ID: <4F34A484.30503@oracle.com> Hi, Could I have one more review for this change, please. 7009098: SA cannot open core files larger than 2GB on Linux 32-bit http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ Thanks, Poonam On 2/9/2012 12:29 PM, Poonam Bajaj wrote: > > On 2/9/2012 12:21 PM, David Holmes wrote: >> Hi Poonam, >> >> On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>>>> There is one more change with which SA should first load libraries >>>>> from the path specified with SA_ALTROOT rather than loading from >>>>> the host system. >>>> >>>> Where does this come from? It is not related to this CR. Is there >>>> another CR indicating the current behaviour is incorrect? Or a spec >>>> for it that indicates it is incorrect? >>>> >>> This change became necessary to open the same customer provided core >>> which required the first change. There is no separate bug filed for >>> this >>> change. >> >> Actually there is: 7009089 >> > Thanks for finding this bug number. I will link both the bugs. > >> Thanks for all the info. Your change agrees with the proposed fix in >> 7009089, and it seems consist with how Solaris checks the alt-root >> path first. >> >> So this looks good to me. >> > Thanks, > Poonam > >> David >> ----- >> >> >>> >>> There is a document in the hotspot repository >>> hotspot/agent/doc/transported_core.html which talks about the >>> transported cores and the use of SA_ALTROOT. >>> >>> " The best possible way to debug a transported core dump is to match >>> the >>> debugger machine to that of core dump machine. i.e., have same Kernel >>> and libthread patch level between the machines. mdb (Solaris modular >>> debugger) may be used to find the Kernel patch level of core dump >>> machine and debugger machine may be brought to the same level. >>> >>> If the matching machine is "far off" in your network, then >>> >>> * consider using rlogin and CLHSDB - SA command line HSDB interface >>> >>> >>> or >>> * use SA remote debugging and debug the core from core machine >>> remotely. >>> >>> But, it may not be feasible to find matching machine to debug. If so, >>> you can copy all application shared objects (and libthread_db.so, if >>> needed) from the core dump machine into your debugger machine's >>> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment >>> variable to point to /export/applibs directory. Note that >>> /export/applibs should either contain matching 'full path' of >>> libraries. >>> i.e., /usr/lib/libthread_db.so from core machine should be under >>> /export/applibs/use/lib directory and >>> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be >>> under /export/applibs/use/java/jre/lib/sparc/client so on or >>> /export/applibs should just contain libthread_db.so, libjvm.so etc. >>> directly. " >>> >>> " On Linux, SA parses core and shared library ELF files. SA *does not* >>> use libthread_db.so or rtld_db.so for core dump debugging (although >>> libthread_db.so is used for live process debugging). But, you may still >>> face problems with transported core dumps, because matching shared >>> objects may not be in the path(s) specified in core dump file. To >>> workaround this, you can define environment variable *SA_ALTROOT* to be >>> the directory where shared libraries are kept. The semantics of this >>> env. variable is same as that for Solaris (please refer above)." >>> >>> So, if SA_ALTROOT is specified, libraries from this path should get >>> loaded and not from the path embedded in the core file. >>> >>> >>> Thanks, >>> Poonam >>> >>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Poonam >>>>> -- >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120210/5f5358c9/attachment.html From john.coomes at oracle.com Thu Feb 9 21:00:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:00:56 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b25 for changeset bb694c151fc7 Message-ID: <20120210050056.91A254743F@hg.openjdk.java.net> Changeset: dbb7283c197b Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/dbb7283c197b Added tag jdk8-b25 for changeset bb694c151fc7 ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:01:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:01:04 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b25 for changeset b376d901e006 Message-ID: <20120210050104.27FE047440@hg.openjdk.java.net> Changeset: 3518639eab6c Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/3518639eab6c Added tag jdk8-b25 for changeset b376d901e006 ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:02:08 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:02:08 +0000 Subject: hg: hsx/hotspot-rt/jdk: 47 new changesets Message-ID: <20120210051648.79B1C47443@hg.openjdk.java.net> Changeset: ad9f1c8970da Author: prr Date: 2012-01-19 12:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ad9f1c8970da 7131153: GetDC called way too many times - causes bad performance. Reviewed-by: igor, jgodinez ! src/windows/native/sun/font/fontpath.c Changeset: f7dda4bbf1f9 Author: lana Date: 2012-01-28 22:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f7dda4bbf1f9 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 84b153cd9bd4 Author: denis Date: 2012-01-19 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/84b153cd9bd4 7121761: creation of java.awt.DataFlavour fails for turkish locale Reviewed-by: anthony ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: e32db6535c05 Author: alexsch Date: 2012-01-23 13:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e32db6535c05 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cc88a9c0474f Author: alexsch Date: 2012-01-23 13:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cc88a9c0474f 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: 19431d07bc19 Author: denis Date: 2012-01-23 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/19431d07bc19 7130140: using horizontal scroll button on mouse causes a message to be printed on stdout Reviewed-by: art ! src/share/classes/java/awt/event/MouseEvent.java Changeset: 5255fd5b0418 Author: denis Date: 2012-01-24 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5255fd5b0418 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b4589ff4457c Author: malenkov Date: 2012-01-24 19:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b4589ff4457c 7121905: grammatically incorrect apostrophe in BeanInfo javadoc Reviewed-by: rupashka ! src/share/classes/java/beans/BeanInfo.java Changeset: 4f2a2bf0ce84 Author: rupashka Date: 2012-01-26 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4f2a2bf0ce84 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: cc9ff174a1c3 Author: alexsch Date: 2012-01-27 16:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cc9ff174a1c3 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 96b5999af66b Author: alexsch Date: 2012-01-27 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/96b5999af66b 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: 6a7109f52966 Author: alexsch Date: 2012-01-27 17:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6a7109f52966 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: bc1c20ac8676 Author: chegar Date: 2012-01-27 13:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bc1c20ac8676 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt Reviewed-by: art, prr, dholmes, alanb ! make/common/Release-embedded.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/jawt/Makefile ! make/sun/xawt/Makefile ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 5dab2d55bc5b Author: lana Date: 2012-01-28 22:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5dab2d55bc5b Merge - test/java/io/File/BlockIsDirectory.java Changeset: 39b661c5867a Author: alexsch Date: 2012-01-30 12:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39b661c5867a 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 7d6c7dd72e25 Author: malenkov Date: 2012-01-31 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7d6c7dd72e25 7122138: IAE thrown because Introspector ignores synthetic methods Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/7122138/Test7122138.java + test/java/beans/Introspector/7122138/pack/Sub.java + test/java/beans/Introspector/7122138/pack/Super.java Changeset: c5c78f293ff8 Author: rupashka Date: 2012-01-31 17:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c5c78f293ff8 7082443: JComboBox not backward compatible (with Java 6) Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java + test/javax/swing/JComboBox/7082443/bug7082443.java Changeset: 363086137375 Author: lana Date: 2012-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/363086137375 Merge Changeset: 313da5d059bf Author: valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: 71200c517524 Author: darcy Date: 2012-01-20 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/71200c517524 4504839: Java libraries should provide support for unsigned integer arithmetic 4215269: Some Integer.toHexString(int) results cannot be decoded back to an int 6322074: Converting integers to string as if unsigned Reviewed-by: mduigou, emcmanus, flar ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Integer/Unsigned.java + test/java/lang/Long/Unsigned.java Changeset: d383b5d128e3 Author: xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 3df0bd3ed880 Author: mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author: mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5e1ad6ad41b7 Merge Changeset: 914711cccc60 Author: darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/914711cccc60 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java Changeset: 237319a01a9a Author: alanb Date: 2012-01-24 09:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/237319a01a9a 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties ! test/ProblemList.txt Changeset: 718bca4e685f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/718bca4e685f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: ohair, dholmes, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: f64ea40293db Author: ksrini Date: 2012-01-24 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f64ea40293db 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Reviewed-by: alanb, chegar ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 303b67074666 Author: lancea Date: 2012-01-24 15:13 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/303b67074666 7132879: address Findbugs issue in WebRowSetXmlWriter Reviewed-by: forax ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Changeset: ceab7e149581 Author: peytoia Date: 2012-01-26 17:06 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ceab7e149581 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java Changeset: 350971f50949 Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/350971f50949 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk Changeset: b518b160607f Author: lancea Date: 2012-01-26 19:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b518b160607f 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Reviewed-by: forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 5ee30ab905db Author: wetmore Date: 2012-01-26 17:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5ee30ab905db 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh Changeset: 7aa5ddfa3c9d Author: okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java Changeset: ff24779c147f Author: valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of "secrity". Reviewed-by: wetmore ! test/Makefile Changeset: 7dbc129d8e5c Author: ksrini Date: 2012-01-28 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7dbc129d8e5c 7127906: (launcher) convert the launcher regression tests to java Reviewed-by: darcy, naoto ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ChangeDataModel.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/I18NJarTest.java + test/tools/launcher/I18NTest.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/Settings.java - test/tools/launcher/SomeException.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java - test/tools/launcher/UnicodeCleanup.java ! test/tools/launcher/UnicodeTest.java - test/tools/launcher/UnicodeTest.sh ! test/tools/launcher/UnresolvedExceptions.java - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 7a25b72b3644 Author: lana Date: 2012-01-28 20:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7a25b72b3644 Merge Changeset: f9fb8c4b4550 Author: dl Date: 2012-01-30 11:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f9fb8c4b4550 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/FutureTask.java + test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java + test/java/util/concurrent/FutureTask/ExplicitSet.java Changeset: 863a20b0bf08 Author: ngmr Date: 2012-01-10 00:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/863a20b0bf08 7123229: (coll) EnumMap.containsValue(null) returns true Summary: java.util.EnumMap.NULL equals() must only be true for itself Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/UniqueNullValue.java Changeset: 13978750cb87 Author: ngmr Date: 2012-01-31 10:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/13978750cb87 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 431bc327f34a Author: sla Date: 2012-01-31 10:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/431bc327f34a 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Summary: Make sure HotSpot and JDK looks for well-known files in the same location Reviewed-by: dholmes, dsamersoff ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! test/ProblemList.txt Changeset: 663a6333105d Author: sla Date: 2012-01-31 04:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/663a6333105d Merge Changeset: 533bc0a10233 Author: lana Date: 2012-01-31 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/533bc0a10233 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: ce62fb7aa1b8 Author: lana Date: 2012-02-07 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce62fb7aa1b8 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 1a99dad28223 Author: yhuang Date: 2012-02-06 18:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1a99dad28223 7129382: change minor unit of VND to 0 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/tablea1.txt Changeset: 930756e55285 Author: yhuang Date: 2012-02-06 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/930756e55285 Merge Changeset: ec17fbe5b8fb Author: katleman Date: 2012-02-08 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ec17fbe5b8fb Merge Changeset: 5aca406e87cb Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5aca406e87cb Added tag jdk8-b25 for changeset ec17fbe5b8fb ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:58:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:58:54 +0000 Subject: hg: hsx/hotspot-rt/langtools: 7 new changesets Message-ID: <20120210055914.A6FF14744B@hg.openjdk.java.net> Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref Changeset: 7d412606d641 Author: lana Date: 2012-01-28 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7d412606d641 Merge Changeset: 520c30f85bb5 Author: lana Date: 2012-02-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/520c30f85bb5 Merge Changeset: b556aa8a99c3 Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b556aa8a99c3 Added tag jdk8-b25 for changeset 520c30f85bb5 ! .hgtags From frederic.parain at oracle.com Fri Feb 10 00:58:58 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Feb 2012 09:58:58 +0100 Subject: Request for Review (S) : 7140868 TEST_BUG: jcmd tests need to use -XX:+UsePerfData In-Reply-To: <4F343EAF.2040404@oracle.com> References: <4F33CC3C.40609@oracle.com> <4F343EAF.2040404@oracle.com> Message-ID: <4F34DC52.5080303@oracle.com> Hi David, Thanks for the review. I'd prefer to keep the $JCMD variable with only the path to the jcmd binary, without any arguments. Having the -J-XX:UsePerfData repeated on every jcmd invocation is not necessarily a bad thing, it will remind the reader that jcmd depends on the perfdata. Fred On 2/9/12 10:46 PM, David Holmes wrote: > Hi Fred, > > On 9/02/2012 11:38 PM, Frederic Parain wrote: >> Here's a very simple fix which adds -J-XX:+UsePerfData >> to all jcmd test in order to pass with the embedded builds. > > Can't you redefine $JCMD to include the -J-XX:+UsePerfData so that it's > needed in fewer places? > > Otherwise seems correct. > > David > >> The CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140868 >> >> The Webrev: >> http://cr.openjdk.java.net/~fparain/7140868/webrev.00/ >> >> I've tested manually with embedded builds that adding >> -J-XX:+UsePerfData is sufficient to pass the tests. >> >> Thanks, >> >> Fred >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri Feb 10 01:27:30 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Feb 2012 10:27:30 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications Message-ID: <4F34E302.1070001@oracle.com> Here's a small fix (one line) for CR 7143760 Memory leak in GarbageCollectionNotifications There's a missing HandleMark at the beginning of the GCNotifier::sendNotificatin() method. Without this HandleMark, all handles used when creating GC notifications are kept alive causing a double leak: in the Java heap and in the thread local handle area of the service thread. Here's the CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 (Warning, the changeset referenced in the CR is not the one containing the original bug). Here's the webrev: http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From Dmitry.Samersoff at oracle.com Fri Feb 10 01:59:33 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 10 Feb 2012 13:59:33 +0400 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F34E302.1070001@oracle.com> References: <4F34E302.1070001@oracle.com> Message-ID: <4F34EA85.600@oracle.com> Frederic, GCNotificationRequest *request = getRequest(); request variable also leaks memory because it will never be deleted on CHECK return path. Could you fix it too? -Dmitry On 2012-02-10 13:27, Frederic Parain wrote: > Here's a small fix (one line) for CR 7143760 Memory leak in > GarbageCollectionNotifications > > There's a missing HandleMark at the beginning of the > GCNotifier::sendNotificatin() method. Without this HandleMark, all > handles used when creating GC notifications are kept alive causing a > double leak: in the Java heap and in the thread local handle area of the > service thread. > > Here's the CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 > (Warning, the changeset referenced in the CR is not the > one containing the original bug). > > Here's the webrev: > http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ > > Thanks, > > Fred > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Fri Feb 10 02:27:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Feb 2012 20:27:49 +1000 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F34EA85.600@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> Message-ID: <4F34F125.8050207@oracle.com> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: > Frederic, > > GCNotificationRequest *request = getRequest(); > > request variable also leaks memory because it will never be deleted on > CHECK return path. Could you fix it too? Further: 211 JavaCalls::call_virtual(&result, 212 gc_mbean_klass, 213 vmSymbols::createGCNotification_name(), 214 vmSymbols::createGCNotification_signature(), 215 &args, 216 CHECK); 217 if (HAS_PENDING_EXCEPTION) { 218 CLEAR_PENDING_EXCEPTION; 219 } 220 221 delete request; The CHECK at @216 will cause a return if there is an exception pending so 217-219 is dead code. This also indicates some confusion about what exceptions this method can leave pending. Or it may be that the CHECK at #216 was meant to be just THREAD. ?? (Strange this is the second example I've seen of this today!) David > > -Dmitry > > > On 2012-02-10 13:27, Frederic Parain wrote: >> Here's a small fix (one line) for CR 7143760 Memory leak in >> GarbageCollectionNotifications >> >> There's a missing HandleMark at the beginning of the >> GCNotifier::sendNotificatin() method. Without this HandleMark, all >> handles used when creating GC notifications are kept alive causing a >> double leak: in the Java heap and in the thread local handle area of the >> service thread. >> >> Here's the CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >> (Warning, the changeset referenced in the CR is not the >> one containing the original bug). >> >> Here's the webrev: >> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >> >> Thanks, >> >> Fred >> > > From frederic.parain at oracle.com Fri Feb 10 02:46:40 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Feb 2012 11:46:40 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F34F125.8050207@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> Message-ID: <4F34F590.80802@oracle.com> I agree that the CHECK path is not memory clean. I'm fixing it, I'll be back with better fix. Thanks, Fred On 2/10/12 11:27 AM, David Holmes wrote: > On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >> Frederic, >> >> GCNotificationRequest *request = getRequest(); >> >> request variable also leaks memory because it will never be deleted on >> CHECK return path. Could you fix it too? > > Further: > > 211 JavaCalls::call_virtual(&result, > 212 gc_mbean_klass, > 213 vmSymbols::createGCNotification_name(), > 214 vmSymbols::createGCNotification_signature(), > 215 &args, > 216 CHECK); > 217 if (HAS_PENDING_EXCEPTION) { > 218 CLEAR_PENDING_EXCEPTION; > 219 } > 220 > 221 delete request; > > The CHECK at @216 will cause a return if there is an exception pending > so 217-219 is dead code. This also indicates some confusion about what > exceptions this method can leave pending. Or it may be that the CHECK at > #216 was meant to be just THREAD. ?? > > (Strange this is the second example I've seen of this today!) > > David > >> >> -Dmitry >> >> >> On 2012-02-10 13:27, Frederic Parain wrote: >>> Here's a small fix (one line) for CR 7143760 Memory leak in >>> GarbageCollectionNotifications >>> >>> There's a missing HandleMark at the beginning of the >>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>> handles used when creating GC notifications are kept alive causing a >>> double leak: in the Java heap and in the thread local handle area of the >>> service thread. >>> >>> Here's the CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>> (Warning, the changeset referenced in the CR is not the >>> one containing the original bug). >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From mikael.gerdin at oracle.com Fri Feb 10 03:29:12 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 10 Feb 2012 12:29:12 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F34E302.1070001@oracle.com> References: <4F34E302.1070001@oracle.com> Message-ID: <3611550.NIulkoApsD@mgerdin-ws> Hi Fred, I ran the repro on a build with your fix applied and it appears that the leak is fixed. Thanks for finding it so quick :) /Mikael On Friday 10 February 2012 10.27.30 Frederic Parain wrote: > Here's a small fix (one line) for CR 7143760 Memory leak in > GarbageCollectionNotifications > > There's a missing HandleMark at the beginning of the > GCNotifier::sendNotificatin() method. Without this HandleMark, all > handles used when creating GC notifications are kept alive causing a > double leak: in the Java heap and in the thread local handle area of the > service thread. > > Here's the CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 > (Warning, the changeset referenced in the CR is not the > one containing the original bug). > > Here's the webrev: > http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ > > Thanks, > > Fred From Dmitry.Samersoff at oracle.com Fri Feb 10 04:14:57 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 10 Feb 2012 16:14:57 +0400 Subject: RR(XS): 7118280 The gbyc00102 JCK7 test causes an assert in JVM 7.0 fastdebug mode Message-ID: <4F350A41.5030706@oracle.com> Hi Everybody, Assert incorrectly triggered by _invokedynamic opcode. Fixed assert. webrev is: http://cr.openjdk.java.net/~dsamersoff/7118280/webrev.01/ -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kevin.walls at oracle.com Fri Feb 10 04:48:10 2012 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 10 Feb 2012 12:48:10 +0000 Subject: Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit In-Reply-To: <4F34A484.30503@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> <4F336ACC.6070106@oracle.com> <4F336D0C.10005@oracle.com> <4F336EC7.3000607@oracle.com> <4F34A484.30503@oracle.com> Message-ID: <4F35120A.2090509@oracle.com> It looks good Poonam! 8-) On 10/02/12 05:00, Poonam Bajaj wrote: > Hi, > > Could I have one more review for this change, please. > > 7009098: SA cannot open core files larger than 2GB on Linux 32-bit > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 > > Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ > > > > Thanks, > Poonam > > On 2/9/2012 12:29 PM, Poonam Bajaj wrote: >> >> On 2/9/2012 12:21 PM, David Holmes wrote: >>> Hi Poonam, >>> >>> On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>>>>> There is one more change with which SA should first load libraries >>>>>> from the path specified with SA_ALTROOT rather than loading from >>>>>> the host system. >>>>> >>>>> Where does this come from? It is not related to this CR. Is there >>>>> another CR indicating the current behaviour is incorrect? Or a spec >>>>> for it that indicates it is incorrect? >>>>> >>>> This change became necessary to open the same customer provided core >>>> which required the first change. There is no separate bug filed for >>>> this >>>> change. >>> >>> Actually there is: 7009089 >>> >> Thanks for finding this bug number. I will link both the bugs. >> >>> Thanks for all the info. Your change agrees with the proposed fix in >>> 7009089, and it seems consist with how Solaris checks the alt-root >>> path first. >>> >>> So this looks good to me. >>> >> Thanks, >> Poonam >> >>> David >>> ----- >>> >>> >>>> >>>> There is a document in the hotspot repository >>>> hotspot/agent/doc/transported_core.html which talks about the >>>> transported cores and the use of SA_ALTROOT. >>>> >>>> " The best possible way to debug a transported core dump is to >>>> match the >>>> debugger machine to that of core dump machine. i.e., have same Kernel >>>> and libthread patch level between the machines. mdb (Solaris modular >>>> debugger) may be used to find the Kernel patch level of core dump >>>> machine and debugger machine may be brought to the same level. >>>> >>>> If the matching machine is "far off" in your network, then >>>> >>>> * consider using rlogin and CLHSDB - SA command line HSDB interface >>>> >>>> >>>> or >>>> * use SA remote debugging and debug the core from core machine >>>> remotely. >>>> >>>> But, it may not be feasible to find matching machine to debug. If so, >>>> you can copy all application shared objects (and libthread_db.so, if >>>> needed) from the core dump machine into your debugger machine's >>>> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment >>>> variable to point to /export/applibs directory. Note that >>>> /export/applibs should either contain matching 'full path' of >>>> libraries. >>>> i.e., /usr/lib/libthread_db.so from core machine should be under >>>> /export/applibs/use/lib directory and >>>> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be >>>> under /export/applibs/use/java/jre/lib/sparc/client so on or >>>> /export/applibs should just contain libthread_db.so, libjvm.so etc. >>>> directly. " >>>> >>>> " On Linux, SA parses core and shared library ELF files. SA *does not* >>>> use libthread_db.so or rtld_db.so for core dump debugging (although >>>> libthread_db.so is used for live process debugging). But, you may >>>> still >>>> face problems with transported core dumps, because matching shared >>>> objects may not be in the path(s) specified in core dump file. To >>>> workaround this, you can define environment variable *SA_ALTROOT* >>>> to be >>>> the directory where shared libraries are kept. The semantics of this >>>> env. variable is same as that for Solaris (please refer above)." >>>> >>>> So, if SA_ALTROOT is specified, libraries from this path should get >>>> loaded and not from the path embedded in the core file. >>>> >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> -- >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120210/f1b77e3a/attachment.html From frederic.parain at oracle.com Fri Feb 10 05:04:14 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 10 Feb 2012 14:04:14 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F34F125.8050207@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> Message-ID: <4F3515CE.9000804@oracle.com> Here's a new webrev addressing the following issues: - the missing HandleMark - the clean up of the GCNotificationRequest instance - removal of the pending exception testing, now exception will be propagated as soon as a method returns with a pending exception http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ Thanks, Fred On 2/10/12 11:27 AM, David Holmes wrote: > On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >> Frederic, >> >> GCNotificationRequest *request = getRequest(); >> >> request variable also leaks memory because it will never be deleted on >> CHECK return path. Could you fix it too? > > Further: > > 211 JavaCalls::call_virtual(&result, > 212 gc_mbean_klass, > 213 vmSymbols::createGCNotification_name(), > 214 vmSymbols::createGCNotification_signature(), > 215 &args, > 216 CHECK); > 217 if (HAS_PENDING_EXCEPTION) { > 218 CLEAR_PENDING_EXCEPTION; > 219 } > 220 > 221 delete request; > > The CHECK at @216 will cause a return if there is an exception pending > so 217-219 is dead code. This also indicates some confusion about what > exceptions this method can leave pending. Or it may be that the CHECK at > #216 was meant to be just THREAD. ?? > > (Strange this is the second example I've seen of this today!) > > David > >> >> -Dmitry >> >> >> On 2012-02-10 13:27, Frederic Parain wrote: >>> Here's a small fix (one line) for CR 7143760 Memory leak in >>> GarbageCollectionNotifications >>> >>> There's a missing HandleMark at the beginning of the >>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>> handles used when creating GC notifications are kept alive causing a >>> double leak: in the Java heap and in the thread local handle area of the >>> service thread. >>> >>> Here's the CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>> (Warning, the changeset referenced in the CR is not the >>> one containing the original bug). >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From daniel.daugherty at oracle.com Fri Feb 10 06:37:11 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Feb 2012 07:37:11 -0700 Subject: RR(XS): 7118280 The gbyc00102 JCK7 test causes an assert in JVM 7.0 fastdebug mode In-Reply-To: <4F350A41.5030706@oracle.com> References: <4F350A41.5030706@oracle.com> Message-ID: <4F352B97.8080408@oracle.com> On 2/10/12 5:14 AM, Dmitry Samersoff wrote: > Hi Everybody, > > Assert incorrectly triggered by _invokedynamic opcode. > Fixed assert. > > webrev is: > > http://cr.openjdk.java.net/~dsamersoff/7118280/webrev.01/ Please update the copyright year to 2012. Thumbs up! src/share/vm/prims/jvmtiClassFileReconstituter.cpp lines 731-732 - Please change '==5' -> '== 5'. Yes, I know the original code had bad spacing... :-) From daniel.daugherty at oracle.com Fri Feb 10 06:47:24 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 10 Feb 2012 07:47:24 -0700 Subject: Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit In-Reply-To: <4F34A484.30503@oracle.com> References: <4F334E76.9030406@oracle.com> <4F336275.7090101@oracle.com> <4F336ACC.6070106@oracle.com> <4F336D0C.10005@oracle.com> <4F336EC7.3000607@oracle.com> <4F34A484.30503@oracle.com> Message-ID: <4F352DFC.3090505@oracle.com> On 2/9/12 10:00 PM, Poonam Bajaj wrote: > Hi, > > Could I have one more review for this change, please. > > 7009098: SA cannot open core files larger than 2GB on Linux 32-bit > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 > > Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ > Thumbs up. agent/src/os/linux/Makefile No comments. agent/src/os/linux/libproc_impl.c No comments. make/linux/makefiles/saproc.make No comments. Dan > > > Thanks, > Poonam > > On 2/9/2012 12:29 PM, Poonam Bajaj wrote: >> >> On 2/9/2012 12:21 PM, David Holmes wrote: >>> Hi Poonam, >>> >>> On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>>>>> There is one more change with which SA should first load libraries >>>>>> from the path specified with SA_ALTROOT rather than loading from >>>>>> the host system. >>>>> >>>>> Where does this come from? It is not related to this CR. Is there >>>>> another CR indicating the current behaviour is incorrect? Or a spec >>>>> for it that indicates it is incorrect? >>>>> >>>> This change became necessary to open the same customer provided core >>>> which required the first change. There is no separate bug filed for >>>> this >>>> change. >>> >>> Actually there is: 7009089 >>> >> Thanks for finding this bug number. I will link both the bugs. >> >>> Thanks for all the info. Your change agrees with the proposed fix in >>> 7009089, and it seems consist with how Solaris checks the alt-root >>> path first. >>> >>> So this looks good to me. >>> >> Thanks, >> Poonam >> >>> David >>> ----- >>> >>> >>>> >>>> There is a document in the hotspot repository >>>> hotspot/agent/doc/transported_core.html which talks about the >>>> transported cores and the use of SA_ALTROOT. >>>> >>>> " The best possible way to debug a transported core dump is to >>>> match the >>>> debugger machine to that of core dump machine. i.e., have same Kernel >>>> and libthread patch level between the machines. mdb (Solaris modular >>>> debugger) may be used to find the Kernel patch level of core dump >>>> machine and debugger machine may be brought to the same level. >>>> >>>> If the matching machine is "far off" in your network, then >>>> >>>> * consider using rlogin and CLHSDB - SA command line HSDB interface >>>> >>>> >>>> or >>>> * use SA remote debugging and debug the core from core machine >>>> remotely. >>>> >>>> But, it may not be feasible to find matching machine to debug. If so, >>>> you can copy all application shared objects (and libthread_db.so, if >>>> needed) from the core dump machine into your debugger machine's >>>> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment >>>> variable to point to /export/applibs directory. Note that >>>> /export/applibs should either contain matching 'full path' of >>>> libraries. >>>> i.e., /usr/lib/libthread_db.so from core machine should be under >>>> /export/applibs/use/lib directory and >>>> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be >>>> under /export/applibs/use/java/jre/lib/sparc/client so on or >>>> /export/applibs should just contain libthread_db.so, libjvm.so etc. >>>> directly. " >>>> >>>> " On Linux, SA parses core and shared library ELF files. SA *does not* >>>> use libthread_db.so or rtld_db.so for core dump debugging (although >>>> libthread_db.so is used for live process debugging). But, you may >>>> still >>>> face problems with transported core dumps, because matching shared >>>> objects may not be in the path(s) specified in core dump file. To >>>> workaround this, you can define environment variable *SA_ALTROOT* >>>> to be >>>> the directory where shared libraries are kept. The semantics of this >>>> env. variable is same as that for Solaris (please refer above)." >>>> >>>> So, if SA_ALTROOT is specified, libraries from this path should get >>>> loaded and not from the path embedded in the core file. >>>> >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> -- >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120210/2bb12c72/attachment-0001.html From paul.hohensee at oracle.com Fri Feb 10 07:17:23 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 10 Feb 2012 10:17:23 -0500 Subject: RR(XS): 7118280 The gbyc00102 JCK7 test causes an assert in JVM 7.0 fastdebug mode In-Reply-To: <4F352B97.8080408@oracle.com> References: <4F350A41.5030706@oracle.com> <4F352B97.8080408@oracle.com> Message-ID: <4F353503.1030203@oracle.com> Looks good, again with Dan's recommendations. Paul On 2/10/12 9:37 AM, Daniel D. Daugherty wrote: > On 2/10/12 5:14 AM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Assert incorrectly triggered by _invokedynamic opcode. >> Fixed assert. >> >> webrev is: >> >> http://cr.openjdk.java.net/~dsamersoff/7118280/webrev.01/ > > Please update the copyright year to 2012. > Thumbs up! > > src/share/vm/prims/jvmtiClassFileReconstituter.cpp > lines 731-732 - Please change '==5' -> '== 5'. Yes, I know the > original code had bad spacing... :-) > From yumin.qi at oracle.com Fri Feb 10 08:31:26 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Fri, 10 Feb 2012 08:31:26 -0800 Subject: Fwd: Re: Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit In-Reply-To: <4F34AF0D.1010805@oracle.com> References: <4F34A484.30503@oracle.com> <4F34A5A1.4040908@oracle.com> <4F34AF0D.1010805@oracle.com> Message-ID: <4F35465E.9090803@oracle.com> Send on open alias. On 2/9/2012 9:45 PM, Yumin Qi wrote: > looks good. > > Thanks > Yumin > > On 2012/2/9 21:05, Poonam Bajaj wrote: >> Not sure if everyone is subscribed to >> serviceability-dev at openjdk.java.net..so forwarding it. ] >> >> I got one review from David Holmes and need one more review to push >> this change to hsx/hotspot-rt. Could someone please review this change. >> >> Thanks, >> Poonam >> >> -------- Original Message -------- >> Subject: Re: Review Request: 7009098: SA cannot open core files >> larger than 2GB on Linux 32-bit >> Date: Fri, 10 Feb 2012 10:30:52 +0530 >> From: Poonam Bajaj >> Organization: Oracle Corporation >> To: serviceability-dev at openjdk.java.net >> >> >> >> Hi, >> >> Could I have one more review for this change, please. >> >> 7009098: SA cannot open core files larger than 2GB on Linux 32-bit >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 >> >> Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ >> >> >> >> Thanks, >> Poonam >> >> On 2/9/2012 12:29 PM, Poonam Bajaj wrote: >>> >>> On 2/9/2012 12:21 PM, David Holmes wrote: >>>> Hi Poonam, >>>> >>>> On 9/02/2012 4:42 PM, Poonam Bajaj wrote: >>>>>>> There is one more change with which SA should first load libraries >>>>>>> from the path specified with SA_ALTROOT rather than loading from >>>>>>> the host system. >>>>>> >>>>>> Where does this come from? It is not related to this CR. Is there >>>>>> another CR indicating the current behaviour is incorrect? Or a spec >>>>>> for it that indicates it is incorrect? >>>>>> >>>>> This change became necessary to open the same customer provided core >>>>> which required the first change. There is no separate bug filed >>>>> for this >>>>> change. >>>> >>>> Actually there is: 7009089 >>>> >>> Thanks for finding this bug number. I will link both the bugs. >>> >>>> Thanks for all the info. Your change agrees with the proposed fix >>>> in 7009089, and it seems consist with how Solaris checks the >>>> alt-root path first. >>>> >>>> So this looks good to me. >>>> >>> Thanks, >>> Poonam >>> >>>> David >>>> ----- >>>> >>>> >>>>> >>>>> There is a document in the hotspot repository >>>>> hotspot/agent/doc/transported_core.html which talks about the >>>>> transported cores and the use of SA_ALTROOT. >>>>> >>>>> " The best possible way to debug a transported core dump is to >>>>> match the >>>>> debugger machine to that of core dump machine. i.e., have same Kernel >>>>> and libthread patch level between the machines. mdb (Solaris modular >>>>> debugger) may be used to find the Kernel patch level of core dump >>>>> machine and debugger machine may be brought to the same level. >>>>> >>>>> If the matching machine is "far off" in your network, then >>>>> >>>>> * consider using rlogin and CLHSDB - SA command line HSDB interface >>>>> >>>>> >>>>> or >>>>> * use SA remote debugging and debug the core from core machine >>>>> remotely. >>>>> >>>>> But, it may not be feasible to find matching machine to debug. If so, >>>>> you can copy all application shared objects (and libthread_db.so, if >>>>> needed) from the core dump machine into your debugger machine's >>>>> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment >>>>> variable to point to /export/applibs directory. Note that >>>>> /export/applibs should either contain matching 'full path' of >>>>> libraries. >>>>> i.e., /usr/lib/libthread_db.so from core machine should be under >>>>> /export/applibs/use/lib directory and >>>>> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be >>>>> under /export/applibs/use/java/jre/lib/sparc/client so on or >>>>> /export/applibs should just contain libthread_db.so, libjvm.so etc. >>>>> directly. " >>>>> >>>>> " On Linux, SA parses core and shared library ELF files. SA *does >>>>> not* >>>>> use libthread_db.so or rtld_db.so for core dump debugging (although >>>>> libthread_db.so is used for live process debugging). But, you may >>>>> still >>>>> face problems with transported core dumps, because matching shared >>>>> objects may not be in the path(s) specified in core dump file. To >>>>> workaround this, you can define environment variable *SA_ALTROOT* >>>>> to be >>>>> the directory where shared libraries are kept. The semantics of this >>>>> env. variable is same as that for Solaris (please refer above)." >>>>> >>>>> So, if SA_ALTROOT is specified, libraries from this path should get >>>>> loaded and not from the path embedded in the core file. >>>>> >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Poonam >>>>>>> -- >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120210/f95b65cf/attachment.html From lana.steuck at oracle.com Fri Feb 10 10:43:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:54 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120210184354.84E8547465@hg.openjdk.java.net> Changeset: 5350cd6e0cc0 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5350cd6e0cc0 Added tag jdk8-b24 for changeset 1a5f1d6b98d6 ! .hgtags Changeset: 221a378e06a3 Author: lana Date: 2012-02-07 10:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/221a378e06a3 Merge Changeset: 2accafff224a Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2accafff224a Added tag jdk8-b25 for changeset 221a378e06a3 ! .hgtags From lana.steuck at oracle.com Fri Feb 10 10:43:58 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:58 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120210184358.74B1847466@hg.openjdk.java.net> Changeset: bb694c151fc7 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bb694c151fc7 Added tag jdk8-b24 for changeset 7836655e2495 ! .hgtags Changeset: dbb7283c197b Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbb7283c197b Added tag jdk8-b25 for changeset bb694c151fc7 ! .hgtags From lana.steuck at oracle.com Fri Feb 10 10:43:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:43:54 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120210184359.2EBE547467@hg.openjdk.java.net> Changeset: e45d6b406d5f Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e45d6b406d5f Added tag jdk8-b24 for changeset b98f0e6dddf9 ! .hgtags Changeset: 79f709a099f4 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/79f709a099f4 Added tag jdk8-b25 for changeset e45d6b406d5f ! .hgtags From lana.steuck at oracle.com Fri Feb 10 10:44:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:02 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20120210184402.CD0A847468@hg.openjdk.java.net> Changeset: b376d901e006 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b376d901e006 Added tag jdk8-b24 for changeset e0d90803439b ! .hgtags Changeset: 3518639eab6c Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3518639eab6c Added tag jdk8-b25 for changeset b376d901e006 ! .hgtags Changeset: 65977d8d348e Author: lana Date: 2012-02-09 22:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/65977d8d348e Merge From lana.steuck at oracle.com Fri Feb 10 10:44:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:06 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20120210184418.4484B47469@hg.openjdk.java.net> Changeset: 5a784dab75f1 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5a784dab75f1 Added tag jdk8-b24 for changeset 6c9d21ca92c4 ! .hgtags Changeset: 520c30f85bb5 Author: lana Date: 2012-02-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/520c30f85bb5 Merge Changeset: b556aa8a99c3 Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b556aa8a99c3 Added tag jdk8-b25 for changeset 520c30f85bb5 ! .hgtags Changeset: 2ac31f40741d Author: lana Date: 2012-02-09 22:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2ac31f40741d Merge From lana.steuck at oracle.com Fri Feb 10 10:44:36 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:36 +0000 Subject: hg: jdk8/tl/hotspot: 74 new changesets Message-ID: <20120210184717.ADD984746B@hg.openjdk.java.net> Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 53a127075045 Author: kvn Date: 2012-01-20 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53a127075045 7131302: connode.cpp:205 Error: ShouldNotReachHere() Summary: Add Value() methods to short and byte Load nodes to truncate constants which does not fit. Reviewed-by: jrose ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 9164b8236699 Author: iveresov Date: 2012-01-20 15:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9164b8236699 7131028: Switch statement takes wrong path Summary: Pass correct type to branch in LIRGenerator::do_SwitchRanges() Reviewed-by: kvn, never ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: a81f60ddab06 Author: never Date: 2012-01-22 14:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a81f60ddab06 7130676: Tiered: assert(bci == 0 || 0<= bci && bciis_loaded() Summary: handle not loaded array klass in Parse::do_checkcast(). Reviewed-by: kvn, never ! src/share/vm/opto/parseHelper.cpp Changeset: 5dbed2f542ff Author: bdelsart Date: 2012-01-26 16:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5dbed2f542ff 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Summary: improvements of TraceMethodHandles for JSR292 Reviewed-by: never, twisti ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 20334ed5ed3c Author: iveresov Date: 2012-01-26 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20334ed5ed3c 7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS Summary: Make sure that CompilationPolicy::event() doesn't throw exceptions Reviewed-by: kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 072384a61312 Author: jrose Date: 2012-01-26 19:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/072384a61312 Merge Changeset: 2e966d967c5c Author: johnc Date: 2012-01-13 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e966d967c5c 7121547: G1: High number mispredicted branches while iterating over the marking bitmap Summary: There is a high number of mispredicted branches associated with calling BitMap::iteratate() from within CMBitMapRO::iterate(). Implement a version of CMBitMapRO::iterate() directly using inline-able routines. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/utilities/bitMap.inline.hpp Changeset: 851b58c26def Author: brutisso Date: 2012-01-16 11:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/851b58c26def 7130334: G1: Change comments and error messages that refer to CMS in g1/concurrentMark.cpp/hpp Summary: Removed references to CMS in the concurrentMark.cpp/hpp files. Reviewed-by: tonyp, jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 9509c20bba28 Author: brutisso Date: 2012-01-16 22:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9509c20bba28 6976060: G1: humongous object allocations should initiate marking cycles when necessary Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 0b3d1ec6eaee Author: tonyp Date: 2012-01-18 10:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b3d1ec6eaee 7097586: G1: improve the per-space output when using jmap -heap Summary: Extend the jmap -heap output for G1 to include some more G1-specific information. Reviewed-by: brutisso, johnc, poonam ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSetBase.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: 7ca7be5a6a0b Author: johnc Date: 2012-01-17 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ca7be5a6a0b 7129271: G1: Interference from multiple threads in PrintGC/PrintGCDetails output Summary: During an initial mark pause, signal the Concurrent Mark thread after the pause output from PrintGC/PrintGCDetails is complete. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: a8a126788ea0 Author: tonyp Date: 2012-01-19 09:13 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a8a126788ea0 7078465: G1: Don't use the undefined value (-1) for the G1 old memory pool max size Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 57025542827f Author: brutisso Date: 2012-01-20 18:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57025542827f 7131791: G1: Asserts in nightly testing due to 6976060 Summary: Create a handle and fake an object to make sure that we don't loose the memory we just allocated Reviewed-by: tonyp, stefank ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6a78aa6ac1ff Author: brutisso Date: 2012-01-23 20:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a78aa6ac1ff 7132311: G1: assert((s == klass->oop_size(this)) || (Universe::heap()->is_gc_active() && ((is_typeArray()... Summary: Move the check for when to call collect() to before we do a humongous object allocation Reviewed-by: stefank, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 877914d90c57 Author: tonyp Date: 2012-01-24 17:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/877914d90c57 7132398: G1: java.lang.IllegalArgumentException: Invalid threshold: 9223372036854775807 > max (1073741824) Summary: Was not passing the right old pool max to the memory pool constructor in the fix for 7078465. Reviewed-by: brutisso, johnc ! src/share/vm/services/g1MemoryPool.cpp Changeset: d30fa85f9994 Author: johnc Date: 2012-01-12 00:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d30fa85f9994 6484965: G1: piggy-back liveness accounting phase on marking Summary: Remove the separate counting phase of concurrent marking by tracking the amount of marked bytes and the cards spanned by marked objects in marking task/worker thread local data structures, which are updated as individual objects are marked. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: eff609af17d7 Author: tonyp Date: 2012-01-25 12:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eff609af17d7 7127706: G1: re-enable survivors during the initial-mark pause Summary: Re-enable survivors during the initial-mark pause. Afterwards, the concurrent marking threads have to scan them and mark everything reachable from them. The next GC will have to wait for the survivors to be scanned. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a5244e07b761 Author: jcoomes Date: 2012-01-25 21:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5244e07b761 7112413: JVM Crash, possibly GC-related Summary: disable UseAdaptiveSizePolicy with the CMS and ParNew Reviewed-by: johnc, brutisso ! src/share/vm/runtime/arguments.cpp Changeset: b4ebad3520bb Author: johnc Date: 2012-01-26 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4ebad3520bb 7133038: G1: Some small profile based optimizations Summary: Some minor profile based optimizations. Reduce the number of branches and branch mispredicts by removing some virtual calls, through closure specalization, and refactoring some conditional statements. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 0a10d80352d5 Author: brutisso Date: 2012-01-27 09:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a10d80352d5 Merge - src/os/bsd/vm/decoder_bsd.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df88f58f3b61 Merge Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78dadb7b16ab Merge Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d708a8cdd022 Merge Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24ec1a6d6ef3 Merge Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6db63e782d3d Merge Changeset: de268c8a8075 Author: phh Date: 2012-01-26 20:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de268c8a8075 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Summary: Add CriticalPriority == MaxPriority+1 and enable scheduling class as well as thread priority to change on Solaris. Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: bf5da1648543 Author: kamg Date: 2012-01-27 10:42 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf5da1648543 Merge ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9e177d44b10f Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e177d44b10f Merge Changeset: a80fd4f45d7a Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a80fd4f45d7a Added tag hs23-b12 for changeset 9e177d44b10f ! .hgtags Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: 9f1c2b7cdfb6 Author: amurillo Date: 2012-01-27 14:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f1c2b7cdfb6 7135385: new hotspot build - hs23-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d96c130c9399 Merge Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: be649fefcdc2 Author: stefank Date: 2012-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be649fefcdc2 7134655: Crash in reference processing when doing single-threaded remarking Summary: Temporarily disabled multi-threaded reference discovery when entering a single-threaded remark phase. Reviewed-by: brutisso, tonyp, jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c03e06373b47 Author: stefank Date: 2012-01-28 01:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c03e06373b47 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: 2eeebe4b4213 Author: brutisso Date: 2012-01-30 15:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2eeebe4b4213 7140909: Visual Studio project builds broken: need to define INCLUDE_TRACE Summary: Add define of INCLUDE_TRACE Reviewed-by: sla, kamg ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ab44ceb4d57 Merge Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags From lana.steuck at oracle.com Fri Feb 10 10:44:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Feb 2012 18:44:54 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20120210184942.23C1C4746C@hg.openjdk.java.net> Changeset: 8da468cf037b Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8da468cf037b Added tag jdk8-b24 for changeset 34029a0c69bb ! .hgtags Changeset: ad9f1c8970da Author: prr Date: 2012-01-19 12:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad9f1c8970da 7131153: GetDC called way too many times - causes bad performance. Reviewed-by: igor, jgodinez ! src/windows/native/sun/font/fontpath.c Changeset: f7dda4bbf1f9 Author: lana Date: 2012-01-28 22:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7dda4bbf1f9 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 84b153cd9bd4 Author: denis Date: 2012-01-19 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84b153cd9bd4 7121761: creation of java.awt.DataFlavour fails for turkish locale Reviewed-by: anthony ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: e32db6535c05 Author: alexsch Date: 2012-01-23 13:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e32db6535c05 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cc88a9c0474f Author: alexsch Date: 2012-01-23 13:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc88a9c0474f 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: 19431d07bc19 Author: denis Date: 2012-01-23 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19431d07bc19 7130140: using horizontal scroll button on mouse causes a message to be printed on stdout Reviewed-by: art ! src/share/classes/java/awt/event/MouseEvent.java Changeset: 5255fd5b0418 Author: denis Date: 2012-01-24 18:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5255fd5b0418 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b4589ff4457c Author: malenkov Date: 2012-01-24 19:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4589ff4457c 7121905: grammatically incorrect apostrophe in BeanInfo javadoc Reviewed-by: rupashka ! src/share/classes/java/beans/BeanInfo.java Changeset: 4f2a2bf0ce84 Author: rupashka Date: 2012-01-26 17:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f2a2bf0ce84 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: cc9ff174a1c3 Author: alexsch Date: 2012-01-27 16:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc9ff174a1c3 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 96b5999af66b Author: alexsch Date: 2012-01-27 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96b5999af66b 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: 6a7109f52966 Author: alexsch Date: 2012-01-27 17:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a7109f52966 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: bc1c20ac8676 Author: chegar Date: 2012-01-27 13:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc1c20ac8676 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt Reviewed-by: art, prr, dholmes, alanb ! make/common/Release-embedded.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/jawt/Makefile ! make/sun/xawt/Makefile ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 5dab2d55bc5b Author: lana Date: 2012-01-28 22:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5dab2d55bc5b Merge - test/java/io/File/BlockIsDirectory.java Changeset: 39b661c5867a Author: alexsch Date: 2012-01-30 12:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b661c5867a 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 7d6c7dd72e25 Author: malenkov Date: 2012-01-31 14:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d6c7dd72e25 7122138: IAE thrown because Introspector ignores synthetic methods Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/7122138/Test7122138.java + test/java/beans/Introspector/7122138/pack/Sub.java + test/java/beans/Introspector/7122138/pack/Super.java Changeset: c5c78f293ff8 Author: rupashka Date: 2012-01-31 17:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5c78f293ff8 7082443: JComboBox not backward compatible (with Java 6) Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java + test/javax/swing/JComboBox/7082443/bug7082443.java Changeset: 363086137375 Author: lana Date: 2012-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/363086137375 Merge Changeset: 533bc0a10233 Author: lana Date: 2012-01-31 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/533bc0a10233 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: ce62fb7aa1b8 Author: lana Date: 2012-02-07 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce62fb7aa1b8 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 1a99dad28223 Author: yhuang Date: 2012-02-06 18:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a99dad28223 7129382: change minor unit of VND to 0 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/tablea1.txt Changeset: 930756e55285 Author: yhuang Date: 2012-02-06 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/930756e55285 Merge Changeset: ec17fbe5b8fb Author: katleman Date: 2012-02-08 19:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec17fbe5b8fb Merge Changeset: 5aca406e87cb Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aca406e87cb Added tag jdk8-b25 for changeset ec17fbe5b8fb ! .hgtags Changeset: 7fc2797cbb4c Author: lana Date: 2012-02-09 22:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fc2797cbb4c Merge From bradford.wetmore at oracle.com Fri Feb 10 19:13:49 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Sat, 11 Feb 2012 03:13:49 +0000 Subject: hg: jdk8/tl/jdk: 7142509: Cipher.doFinal(ByteBuffer, ByteBuffer) fails to process when in.remaining() == 0 Message-ID: <20120211031422.DFCF347479@hg.openjdk.java.net> Changeset: b16cbeb0d213 Author: wetmore Date: 2012-02-10 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16cbeb0d213 7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when in.remaining() == 0 Reviewed-by: valeriep ! src/share/classes/javax/crypto/CipherSpi.java + test/javax/crypto/CipherSpi/DirectBBRemaining.java From xuelei.fan at oracle.com Fri Feb 10 22:19:33 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 11 Feb 2012 06:19:33 +0000 Subject: hg: jdk8/tl/jdk: 7144781: incorrect URLs in JSSE java doc Message-ID: <20120211061952.1900B4747D@hg.openjdk.java.net> Changeset: da8b8ee281f9 Author: xuelei Date: 2012-02-10 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8b8ee281f9 7144781: incorrect URLs in JSSE java doc Reviewed-by: wetmore, skannan ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/SSLParameters.java From chris.hegarty at oracle.com Sun Feb 12 00:49:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 12 Feb 2012 08:49:04 +0000 Subject: hg: jdk8/tl/jdk: 7133367: ResponseCache.put should not be called when setUseCaches(false) Message-ID: <20120212084914.C214A4748E@hg.openjdk.java.net> Changeset: 27a6b299ed6a Author: chegar Date: 2012-02-12 08:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27a6b299ed6a 7133367: ResponseCache.put should not be called when setUseCaches(false) Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/NoCache.java From alan.bateman at oracle.com Sun Feb 12 13:11:23 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 12 Feb 2012 21:11:23 +0000 Subject: hg: jdk8/tl/jdk: 7144895: ProblemList.txt updates (2/2012) Message-ID: <20120212211144.D5B8447493@hg.openjdk.java.net> Changeset: 27e746e6f3fe Author: alanb Date: 2012-02-12 21:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27e746e6f3fe 7144895: ProblemList.txt updates (2/2012) Reviewed-by: darcy, ohair ! test/Makefile ! test/ProblemList.txt ! test/TEST.ROOT From jonathan.gibbons at oracle.com Sun Feb 12 16:44:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 Feb 2012 00:44:48 +0000 Subject: hg: jdk8/tl/langtools: 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests Message-ID: <20120213004453.0CCFF47494@hg.openjdk.java.net> Changeset: cd5ca700da4c Author: jjg Date: 2012-02-12 16:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd5ca700da4c 7144979: incorrect path separator in make/build.xml for Windows when running jtreg tests Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! make/build.xml From david.holmes at oracle.com Sun Feb 12 18:56:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2012 12:56:20 +1000 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F3515CE.9000804@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> Message-ID: <4F387BD4.5090203@oracle.com> Hi Fred, 182 class NotificationMark : public StackObj { Really we should have a general purpose utility class that can serve in this role. This is the second time in a couple of weeks that the need to deal with cleanup with CHECK has been uncovered. Not saying you necessarily need to do it for this CR. 183 // This class is used in GCNitifer::sendNotification to ensure Typo: nitifer :) 203 Handle objGcInfo = createGcInfo(request->gcManager,request->gcStatInfo, CHECK); 212 instanceOop gc_mbean = request->gcManager->get_memory_manager_instance(CHECK); CHECK should only be added to functions that can cause exceptions to become pending. That all said I'm not sure that this fix hasn't gone the wrong way. If sendNotification generates an exception then the serviceThread will terminate. Is that the desired behaviour? Other event processing can't terminate the service thread. David ----- On 10/02/2012 11:04 PM, Frederic Parain wrote: > Here's a new webrev addressing the following issues: > - the missing HandleMark > - the clean up of the GCNotificationRequest instance > - removal of the pending exception testing, now > exception will be propagated as soon as a method > returns with a pending exception > > http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ > > Thanks, > > Fred > > On 2/10/12 11:27 AM, David Holmes wrote: >> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>> Frederic, >>> >>> GCNotificationRequest *request = getRequest(); >>> >>> request variable also leaks memory because it will never be deleted on >>> CHECK return path. Could you fix it too? >> >> Further: >> >> 211 JavaCalls::call_virtual(&result, >> 212 gc_mbean_klass, >> 213 vmSymbols::createGCNotification_name(), >> 214 vmSymbols::createGCNotification_signature(), >> 215 &args, >> 216 CHECK); >> 217 if (HAS_PENDING_EXCEPTION) { >> 218 CLEAR_PENDING_EXCEPTION; >> 219 } >> 220 >> 221 delete request; >> >> The CHECK at @216 will cause a return if there is an exception pending >> so 217-219 is dead code. This also indicates some confusion about what >> exceptions this method can leave pending. Or it may be that the CHECK at >> #216 was meant to be just THREAD. ?? >> >> (Strange this is the second example I've seen of this today!) >> >> David >> >>> >>> -Dmitry >>> >>> >>> On 2012-02-10 13:27, Frederic Parain wrote: >>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>> GarbageCollectionNotifications >>>> >>>> There's a missing HandleMark at the beginning of the >>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>> handles used when creating GC notifications are kept alive causing a >>>> double leak: in the Java heap and in the thread local handle area of >>>> the >>>> service thread. >>>> >>>> Here's the CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>> (Warning, the changeset referenced in the CR is not the >>>> one containing the original bug). >>>> >>>> Here's the webrev: >>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>> >>> > From stuart.marks at oracle.com Sun Feb 12 21:55:05 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Mon, 13 Feb 2012 05:55:05 +0000 Subject: hg: jdk8/tl/jdk: 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Message-ID: <20120213055527.1501647499@hg.openjdk.java.net> Changeset: 445ada5e6b4a Author: smarks Date: 2012-02-12 21:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Reviewed-by: alanb, chegar, lancea, smarks Contributed-by: Mani Sarkar , Michael Barker , Carl Jokl , Dinuk Weerasinghe , Markus Stoy , Tom Anderson ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java From rednaxelafx at gmail.com Sun Feb 12 21:58:16 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 13 Feb 2012 13:58:16 +0800 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F387BD4.5090203@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> Message-ID: Hi all, Tto follow up with what David mentioned: If sendNotification generates an exception then the serviceThread will > terminate. Is that the desired behaviour? Other event processing can't > terminate the service thread. I did a simple test to see what would happen in 7u2 when someone throws an uncaught exception on the Service Thread [1]. And in this test it did make the service thread terminate, because sendNotification() does: try { li.listener.handleNotification(notification, li.handback); } catch (Exception e) { e.printStackTrace(); throw new InternalError("Error in invoking listener"); } And that InternalError gets uncaught, which leads to the termination of the thread. So regardless of what the VM does, it seems like the current behavior of the Service Thread is to terminate whenever a handler throws an exception. Don't know if that's the desired behavior, though. - Kris [1]: https://gist.github.com/1814004 On Mon, Feb 13, 2012 at 10:56 AM, David Holmes wrote: > Hi Fred, > > 182 class NotificationMark : public StackObj { > > Really we should have a general purpose utility class that can serve in > this role. This is the second time in a couple of weeks that the need to > deal with cleanup with CHECK has been uncovered. > > Not saying you necessarily need to do it for this CR. > > 183 // This class is used in GCNitifer::sendNotification to ensure > > Typo: nitifer :) > > 203 Handle objGcInfo = createGcInfo(request->**gcManager,request->gcStatInfo, > CHECK); > > 212 instanceOop gc_mbean = request->gcManager->get_** > memory_manager_instance(CHECK)**; > > CHECK should only be added to functions that can cause exceptions to > become pending. > > That all said I'm not sure that this fix hasn't gone the wrong way. If > sendNotification generates an exception then the serviceThread will > terminate. Is that the desired behaviour? Other event processing can't > terminate the service thread. > > David > ----- > > > > On 10/02/2012 11:04 PM, Frederic Parain wrote: > >> Here's a new webrev addressing the following issues: >> - the missing HandleMark >> - the clean up of the GCNotificationRequest instance >> - removal of the pending exception testing, now >> exception will be propagated as soon as a method >> returns with a pending exception >> >> http://cr.openjdk.java.net/~**fparain/7143760/webrev.01/ >> >> Thanks, >> >> Fred >> >> On 2/10/12 11:27 AM, David Holmes wrote: >> >>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>> >>>> Frederic, >>>> >>>> GCNotificationRequest *request = getRequest(); >>>> >>>> request variable also leaks memory because it will never be deleted on >>>> CHECK return path. Could you fix it too? >>>> >>> >>> Further: >>> >>> 211 JavaCalls::call_virtual(&**result, >>> 212 gc_mbean_klass, >>> 213 vmSymbols::**createGCNotification_name(), >>> 214 vmSymbols::**createGCNotification_**signature(), >>> 215 &args, >>> 216 CHECK); >>> 217 if (HAS_PENDING_EXCEPTION) { >>> 218 CLEAR_PENDING_EXCEPTION; >>> 219 } >>> 220 >>> 221 delete request; >>> >>> The CHECK at @216 will cause a return if there is an exception pending >>> so 217-219 is dead code. This also indicates some confusion about what >>> exceptions this method can leave pending. Or it may be that the CHECK at >>> #216 was meant to be just THREAD. ?? >>> >>> (Strange this is the second example I've seen of this today!) >>> >>> David >>> >>> >>>> -Dmitry >>>> >>>> >>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>> >>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>> GarbageCollectionNotifications >>>>> >>>>> There's a missing HandleMark at the beginning of the >>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>> handles used when creating GC notifications are kept alive causing a >>>>> double leak: in the Java heap and in the thread local handle area of >>>>> the >>>>> service thread. >>>>> >>>>> Here's the CR: >>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7143760 >>>>> (Warning, the changeset referenced in the CR is not the >>>>> one containing the original bug). >>>>> >>>>> Here's the webrev: >>>>> http://cr.openjdk.java.net/~**fparain/7143760/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120213/30b5c99e/attachment.html From david.holmes at oracle.com Sun Feb 12 22:08:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2012 16:08:50 +1000 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> Message-ID: <4F38A8F2.5040302@oracle.com> On 13/02/2012 3:58 PM, Krystal Mok wrote: > Tto follow up with what David mentioned: > > If sendNotification generates an exception then the serviceThread > will terminate. Is that the desired behaviour? Other event > processing can't terminate the service thread. > > > I did a simple test to see what would happen in 7u2 when someone throws > an uncaught exception on the Service Thread [1]. And in this test it did > make the service thread terminate, because sendNotification() does: > > try { > li.listener.handleNotification(notification, li.handback); > } catch (Exception e) { > e.printStackTrace(); > throw new InternalError("Error in invoking listener"); > } To clarify what I was saying, the actual service thread logic does: if (has_jvmti_events) { jvmti_event.post(); } if (sensors_changed) { LowMemoryDetector::process_sensor_changes(jt); } if(has_gc_notification_event) { GCNotifier::sendNotification(CHECK); } So only the GC notification events can trigger its termination due to the exception. If this includes propagating exceptions from listener code then this behaviour definitely seems incorrect to me. David ----- > And that InternalError gets uncaught, which leads to the termination of > the thread. So regardless of what the VM does, it seems like the current > behavior of the Service Thread is to terminate whenever a handler throws > an exception. Don't know if that's the desired behavior, though. > > - Kris > > [1]: https://gist.github.com/1814004 > > On Mon, Feb 13, 2012 at 10:56 AM, David Holmes > wrote: > > Hi Fred, > > 182 class NotificationMark : public StackObj { > > Really we should have a general purpose utility class that can serve > in this role. This is the second time in a couple of weeks that the > need to deal with cleanup with CHECK has been uncovered. > > Not saying you necessarily need to do it for this CR. > > 183 // This class is used in GCNitifer::sendNotification to ensure > > Typo: nitifer :) > > 203 Handle objGcInfo = > createGcInfo(request->__gcManager,request->gcStatInfo, CHECK); > > 212 instanceOop gc_mbean = > request->gcManager->get___memory_manager_instance(CHECK)__; > > CHECK should only be added to functions that can cause exceptions to > become pending. > > That all said I'm not sure that this fix hasn't gone the wrong way. > If sendNotification generates an exception then the serviceThread > will terminate. Is that the desired behaviour? Other event > processing can't terminate the service thread. > > David > ----- > > > > On 10/02/2012 11:04 PM, Frederic Parain wrote: > > Here's a new webrev addressing the following issues: > - the missing HandleMark > - the clean up of the GCNotificationRequest instance > - removal of the pending exception testing, now > exception will be propagated as soon as a method > returns with a pending exception > > http://cr.openjdk.java.net/~__fparain/7143760/webrev.01/ > > > Thanks, > > Fred > > On 2/10/12 11:27 AM, David Holmes wrote: > > On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: > > Frederic, > > GCNotificationRequest *request = getRequest(); > > request variable also leaks memory because it will never > be deleted on > CHECK return path. Could you fix it too? > > > Further: > > 211 JavaCalls::call_virtual(&__result, > 212 gc_mbean_klass, > 213 vmSymbols::__createGCNotification_name(), > 214 vmSymbols::__createGCNotification___signature(), > 215 &args, > 216 CHECK); > 217 if (HAS_PENDING_EXCEPTION) { > 218 CLEAR_PENDING_EXCEPTION; > 219 } > 220 > 221 delete request; > > The CHECK at @216 will cause a return if there is an > exception pending > so 217-219 is dead code. This also indicates some confusion > about what > exceptions this method can leave pending. Or it may be that > the CHECK at > #216 was meant to be just THREAD. ?? > > (Strange this is the second example I've seen of this today!) > > David > > > -Dmitry > > > On 2012-02-10 13:27, Frederic Parain wrote: > > Here's a small fix (one line) for CR 7143760 Memory > leak in > GarbageCollectionNotifications > > There's a missing HandleMark at the beginning of the > GCNotifier::sendNotificatin() method. Without this > HandleMark, all > handles used when creating GC notifications are kept > alive causing a > double leak: in the Java heap and in the thread > local handle area of > the > service thread. > > Here's the CR: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7143760 > > (Warning, the changeset referenced in the CR is not the > one containing the original bug). > > Here's the webrev: > http://cr.openjdk.java.net/~__fparain/7143760/webrev.00/ > > > Thanks, > > Fred > > > > > From poonam.bajaj at sun.com Mon Feb 13 00:05:19 2012 From: poonam.bajaj at sun.com (poonam.bajaj at sun.com) Date: Mon, 13 Feb 2012 08:05:19 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Message-ID: <20120213080523.1E1D44749A@hg.openjdk.java.net> Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make From frederic.parain at oracle.com Mon Feb 13 01:17:01 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 13 Feb 2012 10:17:01 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F387BD4.5090203@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> Message-ID: <4F38D50D.1060109@oracle.com> On 02/13/12 03:56 AM, David Holmes wrote: > Hi Fred, > > 182 class NotificationMark : public StackObj { > > Really we should have a general purpose utility class that can serve in > this role. This is the second time in a couple of weeks that the need to > deal with cleanup with CHECK has been uncovered. > > Not saying you necessarily need to do it for this CR. I agree, but clearly out the scope of this CR. > 183 // This class is used in GCNitifer::sendNotification to ensure > > Typo: nitifer :) > > 203 Handle objGcInfo = > createGcInfo(request->gcManager,request->gcStatInfo, CHECK); > > 212 instanceOop gc_mbean = > request->gcManager->get_memory_manager_instance(CHECK); > > CHECK should only be added to functions that can cause exceptions to > become pending. Oops, I'll revert it. > That all said I'm not sure that this fix hasn't gone the wrong way. If > sendNotification generates an exception then the serviceThread will > terminate. Is that the desired behaviour? Other event processing can't > terminate the service thread. I forgot to check that. The initial notification implementation was using its own thread which was protected against pending exceptions. The service thread is not. I'll add a wrapper around the sendNotification() method to catch all exceptions. Thanks for this useful review. Fred > > On 10/02/2012 11:04 PM, Frederic Parain wrote: >> Here's a new webrev addressing the following issues: >> - the missing HandleMark >> - the clean up of the GCNotificationRequest instance >> - removal of the pending exception testing, now >> exception will be propagated as soon as a method >> returns with a pending exception >> >> http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ >> >> Thanks, >> >> Fred >> >> On 2/10/12 11:27 AM, David Holmes wrote: >>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>>> Frederic, >>>> >>>> GCNotificationRequest *request = getRequest(); >>>> >>>> request variable also leaks memory because it will never be deleted on >>>> CHECK return path. Could you fix it too? >>> >>> Further: >>> >>> 211 JavaCalls::call_virtual(&result, >>> 212 gc_mbean_klass, >>> 213 vmSymbols::createGCNotification_name(), >>> 214 vmSymbols::createGCNotification_signature(), >>> 215 &args, >>> 216 CHECK); >>> 217 if (HAS_PENDING_EXCEPTION) { >>> 218 CLEAR_PENDING_EXCEPTION; >>> 219 } >>> 220 >>> 221 delete request; >>> >>> The CHECK at @216 will cause a return if there is an exception pending >>> so 217-219 is dead code. This also indicates some confusion about what >>> exceptions this method can leave pending. Or it may be that the CHECK at >>> #216 was meant to be just THREAD. ?? >>> >>> (Strange this is the second example I've seen of this today!) >>> >>> David >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>> GarbageCollectionNotifications >>>>> >>>>> There's a missing HandleMark at the beginning of the >>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>> handles used when creating GC notifications are kept alive causing a >>>>> double leak: in the Java heap and in the thread local handle area of >>>>> the >>>>> service thread. >>>>> >>>>> Here's the CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>>> (Warning, the changeset referenced in the CR is not the >>>>> one containing the original bug). >>>>> >>>>> Here's the webrev: >>>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>> >>>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Mon Feb 13 02:11:26 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 13 Feb 2012 11:11:26 +0100 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F387BD4.5090203@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> Message-ID: <4F38E1CE.7010405@oracle.com> Here's the new webrev: http://cr.openjdk.java.net/~fparain/7143760/webrev.02/ The changes are: - fix typo in comments - roll-back wrong THREAD->CHECK modifications - add a wrapper catching exceptions around the method sending notifications in order to prevent premature termination of the service thread. Thanks, Fred On 02/13/12 03:56 AM, David Holmes wrote: > Hi Fred, > > 182 class NotificationMark : public StackObj { > > Really we should have a general purpose utility class that can serve in > this role. This is the second time in a couple of weeks that the need to > deal with cleanup with CHECK has been uncovered. > > Not saying you necessarily need to do it for this CR. > > 183 // This class is used in GCNitifer::sendNotification to ensure > > Typo: nitifer :) > > 203 Handle objGcInfo = > createGcInfo(request->gcManager,request->gcStatInfo, CHECK); > > 212 instanceOop gc_mbean = > request->gcManager->get_memory_manager_instance(CHECK); > > CHECK should only be added to functions that can cause exceptions to > become pending. > > That all said I'm not sure that this fix hasn't gone the wrong way. If > sendNotification generates an exception then the serviceThread will > terminate. Is that the desired behaviour? Other event processing can't > terminate the service thread. > > David > ----- > > > On 10/02/2012 11:04 PM, Frederic Parain wrote: >> Here's a new webrev addressing the following issues: >> - the missing HandleMark >> - the clean up of the GCNotificationRequest instance >> - removal of the pending exception testing, now >> exception will be propagated as soon as a method >> returns with a pending exception >> >> http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ >> >> Thanks, >> >> Fred >> >> On 2/10/12 11:27 AM, David Holmes wrote: >>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>>> Frederic, >>>> >>>> GCNotificationRequest *request = getRequest(); >>>> >>>> request variable also leaks memory because it will never be deleted on >>>> CHECK return path. Could you fix it too? >>> >>> Further: >>> >>> 211 JavaCalls::call_virtual(&result, >>> 212 gc_mbean_klass, >>> 213 vmSymbols::createGCNotification_name(), >>> 214 vmSymbols::createGCNotification_signature(), >>> 215 &args, >>> 216 CHECK); >>> 217 if (HAS_PENDING_EXCEPTION) { >>> 218 CLEAR_PENDING_EXCEPTION; >>> 219 } >>> 220 >>> 221 delete request; >>> >>> The CHECK at @216 will cause a return if there is an exception pending >>> so 217-219 is dead code. This also indicates some confusion about what >>> exceptions this method can leave pending. Or it may be that the CHECK at >>> #216 was meant to be just THREAD. ?? >>> >>> (Strange this is the second example I've seen of this today!) >>> >>> David >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>> GarbageCollectionNotifications >>>>> >>>>> There's a missing HandleMark at the beginning of the >>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>> handles used when creating GC notifications are kept alive causing a >>>>> double leak: in the Java heap and in the thread local handle area of >>>>> the >>>>> service thread. >>>>> >>>>> Here's the CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>>> (Warning, the changeset referenced in the CR is not the >>>>> one containing the original bug). >>>>> >>>>> Here's the webrev: >>>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>> >>>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From vincent.x.ryan at oracle.com Mon Feb 13 06:32:27 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Feb 2012 14:32:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120213143305.349E3474A4@hg.openjdk.java.net> Changeset: 3554f175341a Author: vinnie Date: 2012-02-13 14:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3554f175341a 7142339: PKCS7.java is needlessly creating SHA1PRNG SecureRandom instances when timestamping is not done Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/pkcs/PKCS7.java Changeset: 59bd472746d6 Author: vinnie Date: 2012-02-13 14:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59bd472746d6 Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java From frederic.parain at oracle.com Mon Feb 13 10:06:26 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 13 Feb 2012 18:06:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 15 new changesets Message-ID: <20120213180658.29BF1474AE@hg.openjdk.java.net> Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2f985b6ce7ff Merge Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1bb2838e2fc1 Merge From nils.loodin at oracle.com Mon Feb 13 13:58:03 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Mon, 13 Feb 2012 22:58:03 +0100 Subject: Diagnostic command fixes Message-ID: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> Hey all! The new diagnostic command parser needs some additional specializations for time and bytes, here included. Also a few fixes for crashes for some combinations of commandlines. Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ I would also need a sponsor to get this in.. Regards Nils Loodin From jim.holmlund at sun.com Mon Feb 13 16:02:52 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 14 Feb 2012 00:02:52 +0000 Subject: hg: jdk8/tl/langtools: 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...) Message-ID: <20120214000256.8A6B1474B4@hg.openjdk.java.net> Changeset: 237198ef45f5 Author: jjh Date: 2012-02-13 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/237198ef45f5 7142672: Problems with the value passed to the 'classes' param of JavaCompiler.CompilationTask.getTask(...) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/T7142672/AnnoProcessor.java + test/tools/javac/T7142672/Bug.java + test/tools/javac/T7142672/Test2.java + test/tools/javac/T7142672/Test3.java From coleen.phillimore at oracle.com Mon Feb 13 20:47:47 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Feb 2012 04:47:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Message-ID: <20120214044751.C2903474B7@hg.openjdk.java.net> Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp From david.holmes at oracle.com Mon Feb 13 22:58:43 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Feb 2012 16:58:43 +1000 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F38E1CE.7010405@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> <4F38E1CE.7010405@oracle.com> Message-ID: <4F3A0623.2090608@oracle.com> Hi Fred, On 13/02/2012 8:11 PM, Frederic Parain wrote: > Here's the new webrev: > http://cr.openjdk.java.net/~fparain/7143760/webrev.02/ > > The changes are: > - fix typo in comments > - roll-back wrong THREAD->CHECK modifications > - add a wrapper catching exceptions around the method > sending notifications in order to prevent premature > termination of the service thread. My only concern with this is that I don't see anything in the javax.management docs describing the threading model for notifications and listeners, or for how exceptions from listeners are processed. Developers may assume that uncaught exception processing will occur if their listeners encounter exceptions, whereas the implementation "catches" all exceptions and ignores them. I guess this is more a JMX spec issue. So thumbs up from me. David ----- > Thanks, > > Fred > > On 02/13/12 03:56 AM, David Holmes wrote: >> Hi Fred, >> >> 182 class NotificationMark : public StackObj { >> >> Really we should have a general purpose utility class that can serve in >> this role. This is the second time in a couple of weeks that the need to >> deal with cleanup with CHECK has been uncovered. >> >> Not saying you necessarily need to do it for this CR. >> >> 183 // This class is used in GCNitifer::sendNotification to ensure >> >> Typo: nitifer :) >> >> 203 Handle objGcInfo = >> createGcInfo(request->gcManager,request->gcStatInfo, CHECK); >> >> 212 instanceOop gc_mbean = >> request->gcManager->get_memory_manager_instance(CHECK); >> >> CHECK should only be added to functions that can cause exceptions to >> become pending. >> >> That all said I'm not sure that this fix hasn't gone the wrong way. If >> sendNotification generates an exception then the serviceThread will >> terminate. Is that the desired behaviour? Other event processing can't >> terminate the service thread. >> >> David >> ----- >> >> >> On 10/02/2012 11:04 PM, Frederic Parain wrote: >>> Here's a new webrev addressing the following issues: >>> - the missing HandleMark >>> - the clean up of the GCNotificationRequest instance >>> - removal of the pending exception testing, now >>> exception will be propagated as soon as a method >>> returns with a pending exception >>> >>> http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ >>> >>> Thanks, >>> >>> Fred >>> >>> On 2/10/12 11:27 AM, David Holmes wrote: >>>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>>>> Frederic, >>>>> >>>>> GCNotificationRequest *request = getRequest(); >>>>> >>>>> request variable also leaks memory because it will never be deleted on >>>>> CHECK return path. Could you fix it too? >>>> >>>> Further: >>>> >>>> 211 JavaCalls::call_virtual(&result, >>>> 212 gc_mbean_klass, >>>> 213 vmSymbols::createGCNotification_name(), >>>> 214 vmSymbols::createGCNotification_signature(), >>>> 215 &args, >>>> 216 CHECK); >>>> 217 if (HAS_PENDING_EXCEPTION) { >>>> 218 CLEAR_PENDING_EXCEPTION; >>>> 219 } >>>> 220 >>>> 221 delete request; >>>> >>>> The CHECK at @216 will cause a return if there is an exception pending >>>> so 217-219 is dead code. This also indicates some confusion about what >>>> exceptions this method can leave pending. Or it may be that the >>>> CHECK at >>>> #216 was meant to be just THREAD. ?? >>>> >>>> (Strange this is the second example I've seen of this today!) >>>> >>>> David >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>>> GarbageCollectionNotifications >>>>>> >>>>>> There's a missing HandleMark at the beginning of the >>>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>>> handles used when creating GC notifications are kept alive causing a >>>>>> double leak: in the Java heap and in the thread local handle area of >>>>>> the >>>>>> service thread. >>>>>> >>>>>> Here's the CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>>>> (Warning, the changeset referenced in the CR is not the >>>>>> one containing the original bug). >>>>>> >>>>>> Here's the webrev: >>>>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>> >>>>> >>> > From frederic.parain at oracle.com Tue Feb 14 01:10:39 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 14 Feb 2012 10:10:39 +0100 Subject: Diagnostic command fixes In-Reply-To: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> Message-ID: <4F3A250F.1030805@oracle.com> Hi Nils, I can be the sponsor for this one. Here's my comments: diagnosticFramework.cpp:77-79 why do you need: 77 if (_buffer[_cursor] == _delim) { 78 _cursor++; 79 } When there's this loop just a few lines above: 64 while (_cursor < _len - 1 && _buffer[_cursor] == _delim) { 65 _cursor++; 66 } diagnosticArgument.hpp:2 Copyright years need update diagnosticArgument.cpp:2 Copyright years need update diagnosticArgument:46 Why adding an empty line here? diagnosticArgument:134: Could you replace (str[idx] >= '0' && str[idx] <= '9') with isdigit(str[idx]) ? diagnosticArgument.cpp:212-242: Could you follow Karen recommendation and re-use the atomull() implementation? I think I sent you a webrev about this change. diagnosticFramework.hpp:2 Copyright years need update Fred On 02/13/12 10:58 PM, Nils Loodin wrote: > Hey all! > > The new diagnostic command parser needs some additional specializations for time and bytes, here included. > Also a few fixes for crashes for some combinations of commandlines. > > Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. > > http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ > > I would also need a sponsor to get this in.. > > Regards > Nils Loodin -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Tue Feb 14 02:35:00 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 14 Feb 2012 11:35:00 +0100 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Message-ID: <4F3A38D4.2080403@oracle.com> This is a request for review for 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 The problem occurs when one or several lines printed by the jcmd tool match several rules in the awk script checking the output. The counter counting the number of lines matching the expected pattern is incremented each time the line matches a rule. If the line matches several rules, the counter is incremented several times. When this occurs, the test at the end of the script checking that the number of lines matching the pattern is equal to the number of lines of the output fails. The proposed fix is a modification of the awk script. Each rule checking a pattern now sets a variable to 1 when a match is found, and the variable is added to the counter only once per line. Here's the Webrev: http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh test from the problem list. The test has been fixed (see CR 6986875) but the test was still in the exclusion list. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Tue Feb 14 03:01:19 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 14 Feb 2012 12:01:19 +0100 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Message-ID: <4F3A3EFF.7030306@oracle.com> This is a request for review for 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 The problem occurs when one or several lines printed by the jcmd tool match several rules in the awk script checking the output. The counter counting the number of lines matching the expected pattern is incremented each time the line matches a rule. If the line matches several rules, the counter is incremented several times. When this occurs, the test at the end of the script checking that the number of lines matching the pattern is equal to the number of lines of the output fails. The proposed fix is a modification of the awk script. Each rule checking a pattern now sets a variable to 1 when a match is found, and the variable is added to the counter only once per line. Here's the Webrev: http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh test from the problem list. The test has been fixed (see CR 6986875) but the test was still in the exclusion list. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From vincent.x.ryan at oracle.com Tue Feb 14 03:48:04 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 14 Feb 2012 11:48:04 +0000 Subject: hg: jdk8/tl/jdk: 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc Message-ID: <20120214114829.7A0B1474C0@hg.openjdk.java.net> Changeset: f62077973f9b Author: vinnie Date: 2012-02-14 11:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f62077973f9b 7142888: sun/security/tools/jarsigner/ec.sh fail on sparc Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/ec.sh From daniel.daugherty at oracle.com Tue Feb 14 06:26:05 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Feb 2012 07:26:05 -0700 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F38E1CE.7010405@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> <4F38E1CE.7010405@oracle.com> Message-ID: <4F3A6EFD.2070606@oracle.com> On 2/13/12 3:11 AM, Frederic Parain wrote: > Here's the new webrev: > http://cr.openjdk.java.net/~fparain/7143760/webrev.02/ Please update the copyright years to 2012. src/share/vm/services/gcNotifier.hpp No comment. src/share/vm/services/gcNotifier.cpp nit line 185: space missing in 'if(' (yes, I know you didn't break that) nit line 212: missing space after ',' (you fixed one but not the other) Nice refactoring. In the old code, CLEAR_PENDING_EXCEPTION would not be called if getRequest() returned NULL. In the new code, it will. I don't think that will make much of a difference, but I'm not an expert in this code... Thumbs up. Dan > > The changes are: > - fix typo in comments > - roll-back wrong THREAD->CHECK modifications > - add a wrapper catching exceptions around the method > sending notifications in order to prevent premature > termination of the service thread. > > Thanks, > > Fred > > On 02/13/12 03:56 AM, David Holmes wrote: >> Hi Fred, >> >> 182 class NotificationMark : public StackObj { >> >> Really we should have a general purpose utility class that can serve in >> this role. This is the second time in a couple of weeks that the need to >> deal with cleanup with CHECK has been uncovered. >> >> Not saying you necessarily need to do it for this CR. >> >> 183 // This class is used in GCNitifer::sendNotification to ensure >> >> Typo: nitifer :) >> >> 203 Handle objGcInfo = >> createGcInfo(request->gcManager,request->gcStatInfo, CHECK); >> >> 212 instanceOop gc_mbean = >> request->gcManager->get_memory_manager_instance(CHECK); >> >> CHECK should only be added to functions that can cause exceptions to >> become pending. >> >> That all said I'm not sure that this fix hasn't gone the wrong way. If >> sendNotification generates an exception then the serviceThread will >> terminate. Is that the desired behaviour? Other event processing can't >> terminate the service thread. >> >> David >> ----- >> >> >> On 10/02/2012 11:04 PM, Frederic Parain wrote: >>> Here's a new webrev addressing the following issues: >>> - the missing HandleMark >>> - the clean up of the GCNotificationRequest instance >>> - removal of the pending exception testing, now >>> exception will be propagated as soon as a method >>> returns with a pending exception >>> >>> http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ >>> >>> Thanks, >>> >>> Fred >>> >>> On 2/10/12 11:27 AM, David Holmes wrote: >>>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>>>> Frederic, >>>>> >>>>> GCNotificationRequest *request = getRequest(); >>>>> >>>>> request variable also leaks memory because it will never be >>>>> deleted on >>>>> CHECK return path. Could you fix it too? >>>> >>>> Further: >>>> >>>> 211 JavaCalls::call_virtual(&result, >>>> 212 gc_mbean_klass, >>>> 213 vmSymbols::createGCNotification_name(), >>>> 214 vmSymbols::createGCNotification_signature(), >>>> 215 &args, >>>> 216 CHECK); >>>> 217 if (HAS_PENDING_EXCEPTION) { >>>> 218 CLEAR_PENDING_EXCEPTION; >>>> 219 } >>>> 220 >>>> 221 delete request; >>>> >>>> The CHECK at @216 will cause a return if there is an exception pending >>>> so 217-219 is dead code. This also indicates some confusion about what >>>> exceptions this method can leave pending. Or it may be that the >>>> CHECK at >>>> #216 was meant to be just THREAD. ?? >>>> >>>> (Strange this is the second example I've seen of this today!) >>>> >>>> David >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>>> GarbageCollectionNotifications >>>>>> >>>>>> There's a missing HandleMark at the beginning of the >>>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>>> handles used when creating GC notifications are kept alive causing a >>>>>> double leak: in the Java heap and in the thread local handle area of >>>>>> the >>>>>> service thread. >>>>>> >>>>>> Here's the CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>>>> (Warning, the changeset referenced in the CR is not the >>>>>> one containing the original bug). >>>>>> >>>>>> Here's the webrev: >>>>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>> >>>>> >>> > From keith.mcguigan at oracle.com Tue Feb 14 06:31:22 2012 From: keith.mcguigan at oracle.com (keith mcguigan) Date: Tue, 14 Feb 2012 09:31:22 -0500 Subject: Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications In-Reply-To: <4F38E1CE.7010405@oracle.com> References: <4F34E302.1070001@oracle.com> <4F34EA85.600@oracle.com> <4F34F125.8050207@oracle.com> <4F3515CE.9000804@oracle.com> <4F387BD4.5090203@oracle.com> <4F38E1CE.7010405@oracle.com> Message-ID: <4F3A703A.6000703@oracle.com> Looks good to me. -- - Keith Frederic Parain wrote: > Here's the new webrev: > http://cr.openjdk.java.net/~fparain/7143760/webrev.02/ > > The changes are: > - fix typo in comments > - roll-back wrong THREAD->CHECK modifications > - add a wrapper catching exceptions around the method > sending notifications in order to prevent premature > termination of the service thread. > > Thanks, > > Fred > > On 02/13/12 03:56 AM, David Holmes wrote: >> Hi Fred, >> >> 182 class NotificationMark : public StackObj { >> >> Really we should have a general purpose utility class that can serve in >> this role. This is the second time in a couple of weeks that the need to >> deal with cleanup with CHECK has been uncovered. >> >> Not saying you necessarily need to do it for this CR. >> >> 183 // This class is used in GCNitifer::sendNotification to ensure >> >> Typo: nitifer :) >> >> 203 Handle objGcInfo = >> createGcInfo(request->gcManager,request->gcStatInfo, CHECK); >> >> 212 instanceOop gc_mbean = >> request->gcManager->get_memory_manager_instance(CHECK); >> >> CHECK should only be added to functions that can cause exceptions to >> become pending. >> >> That all said I'm not sure that this fix hasn't gone the wrong way. If >> sendNotification generates an exception then the serviceThread will >> terminate. Is that the desired behaviour? Other event processing can't >> terminate the service thread. >> >> David >> ----- >> >> >> On 10/02/2012 11:04 PM, Frederic Parain wrote: >>> Here's a new webrev addressing the following issues: >>> - the missing HandleMark >>> - the clean up of the GCNotificationRequest instance >>> - removal of the pending exception testing, now >>> exception will be propagated as soon as a method >>> returns with a pending exception >>> >>> http://cr.openjdk.java.net/~fparain/7143760/webrev.01/ >>> >>> Thanks, >>> >>> Fred >>> >>> On 2/10/12 11:27 AM, David Holmes wrote: >>>> On 10/02/2012 7:59 PM, Dmitry Samersoff wrote: >>>>> Frederic, >>>>> >>>>> GCNotificationRequest *request = getRequest(); >>>>> >>>>> request variable also leaks memory because it will never be deleted on >>>>> CHECK return path. Could you fix it too? >>>> >>>> Further: >>>> >>>> 211 JavaCalls::call_virtual(&result, >>>> 212 gc_mbean_klass, >>>> 213 vmSymbols::createGCNotification_name(), >>>> 214 vmSymbols::createGCNotification_signature(), >>>> 215 &args, >>>> 216 CHECK); >>>> 217 if (HAS_PENDING_EXCEPTION) { >>>> 218 CLEAR_PENDING_EXCEPTION; >>>> 219 } >>>> 220 >>>> 221 delete request; >>>> >>>> The CHECK at @216 will cause a return if there is an exception pending >>>> so 217-219 is dead code. This also indicates some confusion about what >>>> exceptions this method can leave pending. Or it may be that the >>>> CHECK at >>>> #216 was meant to be just THREAD. ?? >>>> >>>> (Strange this is the second example I've seen of this today!) >>>> >>>> David >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-02-10 13:27, Frederic Parain wrote: >>>>>> Here's a small fix (one line) for CR 7143760 Memory leak in >>>>>> GarbageCollectionNotifications >>>>>> >>>>>> There's a missing HandleMark at the beginning of the >>>>>> GCNotifier::sendNotificatin() method. Without this HandleMark, all >>>>>> handles used when creating GC notifications are kept alive causing a >>>>>> double leak: in the Java heap and in the thread local handle area of >>>>>> the >>>>>> service thread. >>>>>> >>>>>> Here's the CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760 >>>>>> (Warning, the changeset referenced in the CR is not the >>>>>> one containing the original bug). >>>>>> >>>>>> Here's the webrev: >>>>>> http://cr.openjdk.java.net/~fparain/7143760/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>> >>>>> >>> > From frederic.parain at oracle.com Tue Feb 14 09:02:11 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 14 Feb 2012 17:02:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7143760: Memory leak in GarbageCollectionNotifications Message-ID: <20120214170216.62EE6474CA@hg.openjdk.java.net> Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp From nils.loodin at oracle.com Tue Feb 14 09:29:19 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 14 Feb 2012 18:29:19 +0100 Subject: Diagnostic command fixes In-Reply-To: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> Message-ID: <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> Thanks all for suggestions on improvements. I have an updated webrev here: http://cr.openjdk.java.net/~nloodin/7145243/webrev.01/ Regards Nils Loodin PS: Note - Frederic Parain has graciously taken upon himself to sponsor this. Many thanks! DS On Feb 13, 2012, at 22:58 , Nils Loodin wrote: > Hey all! > > The new diagnostic command parser needs some additional specializations for time and bytes, here included. > Also a few fixes for crashes for some combinations of commandlines. > > Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. > > http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ > > I would also need a sponsor to get this in.. > > Regards > Nils Loodin From nils.loodin at oracle.com Tue Feb 14 09:33:33 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 14 Feb 2012 18:33:33 +0100 Subject: Diagnostic command fixes In-Reply-To: <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> Message-ID: <3AEBD916-57AB-480B-908C-46B76443FD49@oracle.com> Forgot an important point - the testing First I ran all the testing we have for the tracing framework that makes use of these commands. I have also debugged through with frivolous command lines to make sure we don't do anything bad, like crash. Also I've manually tried to use all the combinations of the command line arguments I can think of that should work, and that shouldn't. Regards Nils Loodin On Feb 14, 2012, at 18:29 , Nils Loodin wrote: > Thanks all for suggestions on improvements. > I have an updated webrev here: > http://cr.openjdk.java.net/~nloodin/7145243/webrev.01/ > > Regards > Nils Loodin > > PS: Note - Frederic Parain has graciously taken upon himself to sponsor this. Many thanks! > > DS > > On Feb 13, 2012, at 22:58 , Nils Loodin wrote: > >> Hey all! >> >> The new diagnostic command parser needs some additional specializations for time and bytes, here included. >> Also a few fixes for crashes for some combinations of commandlines. >> >> Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. >> >> http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ >> >> I would also need a sponsor to get this in.. >> >> Regards >> Nils Loodin > From karen.kinnear at oracle.com Tue Feb 14 09:55:02 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 14 Feb 2012 12:55:02 -0500 Subject: Diagnostic command fixes In-Reply-To: <3AEBD916-57AB-480B-908C-46B76443FD49@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> <3AEBD916-57AB-480B-908C-46B76443FD49@oracle.com> Message-ID: Thank you Nils :-) I had a question on the DCmdArgument - I think I am not reading this correctly: Couple of questions please: 1) What is this doing? if (idx == len) { 143 // only accept missing unit if the value is 0 144 if (_value._time != 0) { 145 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), 146 "Integer parsing error nanotime value: unit required"); 147 } else { 148 _value._nanotime = 0; 149 strcpy(_value._unit, "ns"); 150 return; I haven't seen the specification at this level of detail, but I thought that if you entered a digit value with no units that you got ns by default - i.e. we need to be able to parse units, but they are not required. 2) What does this comment mean: // WARNING StringArrayArgument can only be used as an option, it cannot be // used as an argument with the DCmdParser ... DCmdArgument -- what can't you do with it more specifically please? Do you mean you can't pass it as an argument to parse_value? 3) diagnosticFramework.cpp: copyright 2012NAME -- oops thanks, Karen On Feb 14, 2012, at 12:33 PM, Nils Loodin wrote: > Forgot an important point - the testing > > First I ran all the testing we have for the tracing framework that makes use of these commands. > I have also debugged through with frivolous command lines to make sure we don't do anything bad, like crash. > Also I've manually tried to use all the combinations of the command line arguments I can think of that should work, and that shouldn't. > > Regards > Nils Loodin > > On Feb 14, 2012, at 18:29 , Nils Loodin wrote: > >> Thanks all for suggestions on improvements. >> I have an updated webrev here: >> http://cr.openjdk.java.net/~nloodin/7145243/webrev.01/ >> >> Regards >> Nils Loodin >> >> PS: Note - Frederic Parain has graciously taken upon himself to sponsor this. Many thanks! >> >> DS >> >> On Feb 13, 2012, at 22:58 , Nils Loodin wrote: >> >>> Hey all! >>> >>> The new diagnostic command parser needs some additional specializations for time and bytes, here included. >>> Also a few fixes for crashes for some combinations of commandlines. >>> >>> Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. >>> >>> http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ >>> >>> I would also need a sponsor to get this in.. >>> >>> Regards >>> Nils Loodin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120214/963e7ea4/attachment-0001.html From frederic.parain at oracle.com Tue Feb 14 10:27:33 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 14 Feb 2012 19:27:33 +0100 Subject: Diagnostic command fixes In-Reply-To: References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> <3AEBD916-57AB-480B-908C-46B76443FD49@oracle.com> Message-ID: <4F3AA795.1070007@oracle.com> On 14/02/2012 18:55, Karen Kinnear wrote: > Thank you Nils :-) > > I had a question on the DCmdArgument - I think I am > not reading > this correctly: > > Couple of questions please: > > I haven't seen the specification at this level of detail, but I thought > that if > you entered a digit value with no units that you got ns by default - > i.e. we need to > be able to parse units, but they are not required. This is code matches the behavior of the JRockit parser, if the specification has changed to consider digit value with no units as ns, then we can remove this logic. Personally, I'd prefer this new semantic. > 2) What does this comment mean: > > // WARNING StringArrayArgument can only be used as an option, it cannot be > // used as an argument with the DCmdParser > ... DCmdArgument > > -- what can't you do with it more specifically please? Do you mean you can't > pass it as an argument to parse_value? With the DCmdParser, "options" are defined with a "key=value" syntax and can be specified in any order. "arguments" don't have key, just a value and are identified by their position on the command line (options are ignored when positions are computed). There's actually no way to specify that an argument can be passed at multiple positions. StringArrayArgument is an argument type defined to accept multiple strings. As it is not possible to specify the multiple position for an argument, StringArrayArgument can only used as an "option", each string being preceded by the same key. Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From karen.kinnear at oracle.com Tue Feb 14 10:51:46 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 14 Feb 2012 13:51:46 -0500 Subject: Diagnostic command fixes In-Reply-To: <4F3AA795.1070007@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> <3AEBD916-57AB-480B-908C-46B76443FD49@oracle.com> <4F3AA795.1070007@oracle.com> Message-ID: Frederic, Nils, Just fix the copyright then. responses inline ... On Feb 14, 2012, at 1:27 PM, Frederic Parain wrote: > > > On 14/02/2012 18:55, Karen Kinnear wrote: >> Thank you Nils :-) >> >> I had a question on the DCmdArgument - I think I am >> not reading >> this correctly: >> >> Couple of questions please: >> >> I haven't seen the specification at this level of detail, but I thought >> that if >> you entered a digit value with no units that you got ns by default - >> i.e. we need to >> be able to parse units, but they are not required. > > This is code matches the behavior of the JRockit parser, if the > specification has changed to consider digit value with no units as > ns, then we can remove this logic. Personally, I'd prefer this new > semantic. This was my misunderstanding then. I also looked to see how hotspot handles time value defaults, since my goal is to have dcmd parsing be a logical extension of how hotspot handles things today. Right now the command-line arguments do NOT have a default unit - in fact many of the names explicitly include Millis. So I would leave this alone as requiring units. > >> 2) What does this comment mean: >> >> // WARNING StringArrayArgument can only be used as an option, it cannot be >> // used as an argument with the DCmdParser >> ... DCmdArgument >> >> -- what can't you do with it more specifically please? Do you mean you can't >> pass it as an argument to parse_value? > > With the DCmdParser, "options" are defined with a "key=value" syntax and > can be specified in any order. "arguments" don't have key, just a value > and are identified by their position on the command line (options are > ignored when positions are computed). There's actually no way to specify > that an argument can be passed at multiple positions. > StringArrayArgument is an argument type defined to accept multiple > strings. As it is not possible to specify the multiple position for > an argument, StringArrayArgument can only used as an "option", each > string being preceded by the same key. Thank you - I remember when you explained this to me when you first added the distinction between options and arguments. thanks, Karen > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From keith.mcguigan at oracle.com Tue Feb 14 13:20:48 2012 From: keith.mcguigan at oracle.com (keith mcguigan) Date: Tue, 14 Feb 2012 16:20:48 -0500 Subject: Request for code review (smallest review ever) Message-ID: <4F3AD030.6070408@oracle.com> Well, ok, I guess it's not the smallest code change -- I think I've matched this before -- but I guarantee you won't see one smaller than this! It's a one-liner (a one-character-er) to accept 0 as a successful return from an ioctl() call, for registering dtrace providers. http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ -- - Keith From paul.hohensee at oracle.com Tue Feb 14 13:25:20 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 14 Feb 2012 16:25:20 -0500 Subject: Request for code review (smallest review ever) In-Reply-To: <4F3AD030.6070408@oracle.com> References: <4F3AD030.6070408@oracle.com> Message-ID: <4F3AD140.6050301@oracle.com> Looks good. Paul On 2/14/12 4:20 PM, keith mcguigan wrote: > > Well, ok, I guess it's not the smallest code change -- I think I've > matched this before -- but I guarantee you won't see one smaller than > this! > > It's a one-liner (a one-character-er) to accept 0 as a successful > return from an ioctl() call, for registering dtrace providers. > > http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ > > -- > - Keith > From Dmitry.Samersoff at oracle.com Tue Feb 14 13:26:33 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Feb 2012 01:26:33 +0400 Subject: Request for code review (smallest review ever) In-Reply-To: <4F3AD030.6070408@oracle.com> References: <4F3AD030.6070408@oracle.com> Message-ID: <4F3AD189.9000501@oracle.com> Keith, Looks good for me. Thank you for catching it! On 2012-02-15 01:20, keith mcguigan wrote: > > Well, ok, I guess it's not the smallest code change -- I think I've > matched this before -- but I guarantee you won't see one smaller than this! > > It's a one-liner (a one-character-er) to accept 0 as a successful return > from an ioctl() call, for registering dtrace providers. > > http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ > > -- > - Keith > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Tue Feb 14 15:25:56 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Feb 2012 15:25:56 -0800 Subject: Request for code review (smallest review ever) In-Reply-To: <4F3AD030.6070408@oracle.com> References: <4F3AD030.6070408@oracle.com> Message-ID: <4F3AED84.6030301@oracle.com> Looks good. The date in the copyright comment will be fixed by RE anyway. Thanks, Serguei On 2/14/12 1:20 PM, keith mcguigan wrote: > > Well, ok, I guess it's not the smallest code change -- I think I've > matched this before -- but I guarantee you won't see one smaller than > this! > > It's a one-liner (a one-character-er) to accept 0 as a successful > return from an ioctl() call, for registering dtrace providers. > > http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ > > -- > - Keith > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120214/858acdea/attachment.html From keith.mcguigan at oracle.com Tue Feb 14 15:31:44 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 14 Feb 2012 23:31:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120214233150.D3CB6474D9@hg.openjdk.java.net> Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a9ac4910e7f2 Merge From maurizio.cimadamore at oracle.com Tue Feb 14 15:54:11 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 14 Feb 2012 23:54:11 +0000 Subject: hg: jdk8/tl/langtools: 7142086: performance problem in Check.checkOverrideClashes(...) Message-ID: <20120214235415.85ADC474DA@hg.openjdk.java.net> Changeset: 84b61130cbed Author: mcimadamore Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84b61130cbed 7142086: performance problem in Check.checkOverrideClashes(...) Summary: Code in Check.checkOverrideClashes() causes too many calls to MethodSymbol.overrides Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/7142086/T7142086.java From coleen.phillimore at oracle.com Tue Feb 14 18:15:41 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Feb 2012 02:15:41 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120215021547.59642474DC@hg.openjdk.java.net> Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cf772dff4bfd Merge From david.holmes at oracle.com Tue Feb 14 19:03:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2012 13:03:46 +1000 Subject: Diagnostic command fixes In-Reply-To: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> Message-ID: <4F3B2092.9070309@oracle.com> Hi Nils, I only glanced at this and though the change in thread.cpp a little strange: 3401 // Set flag that basic initialization has completed. Used by exceptions and various 3402 // debug stuff, that does not work until all basic classes have been initialized. 3403 set_init_completed(); 3404 3405 #ifndef USDT2 3406 HS_DTRACE_PROBE(hotspot, vm__init__end); 3407 #else /* USDT2 */ 3408 HOTSPOT_VM_INIT_END(); 3409 #endif /* USDT2 */ 3410 3411 // Must be run after init_ft which initializes ft_enabled 3412 if (TRACE_INITIALIZE() != JNI_OK) { 3413 vm_exit_during_initialization("Failed to initialize tracing backend"); 3414 } Seems odd to move something that can abort VM initialization to _after_ the point where we have set_init_completed() and posted vm__init__end. Surely this should go above there. Also are we certain that none of the preceding initialization code will lead to other TRACE related code that will require that TRACE has already been initialized? (I seem to recall from sideband email that this had to move until after IllegalArgumentException had been initialized incase initialization failed). Speaking of initializing IllegalArgumentException ... the else clause for InitializeJavaLangExceptionsErrors seems to be getting out of sync with the if clause. That said I wonder if anything can even work if InitializeJavaLangExceptionsErrors were set false? Cheers, David On 14/02/2012 7:58 AM, Nils Loodin wrote: > Hey all! > > The new diagnostic command parser needs some additional specializations for time and bytes, here included. > Also a few fixes for crashes for some combinations of commandlines. > > Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. > > http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ > > I would also need a sponsor to get this in.. > > Regards > Nils Loodin From david.holmes at oracle.com Tue Feb 14 23:34:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2012 17:34:09 +1000 Subject: Request for code review (smallest review ever) In-Reply-To: <4F3AD030.6070408@oracle.com> References: <4F3AD030.6070408@oracle.com> Message-ID: <4F3B5FF1.9020604@oracle.com> On 15/02/2012 7:20 AM, keith mcguigan wrote: > > Well, ok, I guess it's not the smallest code change -- I think I've > matched this before -- but I guarantee you won't see one smaller than this! > > It's a one-liner (a one-character-er) to accept 0 as a successful return > from an ioctl() call, for registering dtrace providers. > > http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ Have to ask - why have we not noticed this before? No test coverage? David > -- > - Keith > From keith.mcguigan at oracle.com Tue Feb 14 23:47:23 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 15 Feb 2012 07:47:23 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120215074729.8AA17474E3@hg.openjdk.java.net> Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/91a81502a27d Merge From Alan.Bateman at oracle.com Wed Feb 15 01:04:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 09:04:27 +0000 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently In-Reply-To: <4F3A3EFF.7030306@oracle.com> References: <4F3A3EFF.7030306@oracle.com> Message-ID: <4F3B751B.5080803@oracle.com> On 14/02/2012 11:01, Frederic Parain wrote: > This is a request for review for 7144833: > sun/tools/jcmd/jcmd-Defaults.sh failing intermittently > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 > > The problem occurs when one or several lines printed by the jcmd tool > match several rules in the awk script checking the output. The counter > counting the number of lines matching the expected pattern is > incremented each time the line matches a rule. If the line matches > several rules, the counter is incremented several times. When this > occurs, the test at the end of the script checking that the number > of lines matching the pattern is equal to the number of lines of the > output fails. > > The proposed fix is a modification of the awk script. Each rule > checking a pattern now sets a variable to 1 when a match is found, > and the variable is added to the counter only once per line. > > Here's the Webrev: > > http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ > > The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh > test from the problem list. The test has been fixed (see CR 6986875) > but the test was still in the exclusion list. Looks good to me although you might want to check the indentation in the BEGIN block. Also thanks for updating the ProblemList file. -Alan From frederic.parain at oracle.com Wed Feb 15 02:20:18 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 10:20:18 +0000 Subject: hg: jdk8/tl/jdk: 7140868: TEST_BUG: jcmd tests need to use -XX:+UsePerfData Message-ID: <20120215102030.50B12474E7@hg.openjdk.java.net> Changeset: 13aef38438d8 Author: fparain Date: 2012-02-14 07:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13aef38438d8 7140868: TEST_BUG: jcmd tests need to use -XX:+UsePerfData Reviewed-by: fparain, dholmes ! test/sun/tools/jcmd/jcmd-Defaults.sh ! test/sun/tools/jcmd/jcmd-f.sh ! test/sun/tools/jcmd/jcmd-help-help.sh ! test/sun/tools/jcmd/jcmd-help.sh ! test/sun/tools/jcmd/jcmd-pid.sh From frederic.parain at oracle.com Wed Feb 15 02:22:42 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 15 Feb 2012 11:22:42 +0100 Subject: Request for Review: 7144833 sun/tools/jcmd/jcmd-Defaults.sh failing intermittently In-Reply-To: <4F3B751B.5080803@oracle.com> References: <4F3A3EFF.7030306@oracle.com> <4F3B751B.5080803@oracle.com> Message-ID: <4F3B8772.8050407@oracle.com> Thanks Alan, I've fixed the indentation in the BEGIN block. Fred On 02/15/12 10:04 AM, Alan Bateman wrote: > On 14/02/2012 11:01, Frederic Parain wrote: >> This is a request for review for 7144833: >> sun/tools/jcmd/jcmd-Defaults.sh failing intermittently >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144833 >> >> The problem occurs when one or several lines printed by the jcmd tool >> match several rules in the awk script checking the output. The counter >> counting the number of lines matching the expected pattern is >> incremented each time the line matches a rule. If the line matches >> several rules, the counter is incremented several times. When this >> occurs, the test at the end of the script checking that the number >> of lines matching the pattern is equal to the number of lines of the >> output fails. >> >> The proposed fix is a modification of the awk script. Each rule >> checking a pattern now sets a variable to 1 when a match is found, >> and the variable is added to the counter only once per line. >> >> Here's the Webrev: >> >> http://cr.openjdk.java.net/~fparain/7144833/webrev.00/ >> >> The webrev also contains the removal of the sun/tools/jps/jps-Vvml.sh >> test from the problem list. The test has been fixed (see CR 6986875) >> but the test was still in the exclusion list. > Looks good to me although you might want to check the indentation in the > BEGIN block. > > Also thanks for updating the ProblemList file. > > -Alan -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From staffan.larsen at oracle.com Wed Feb 15 02:29:27 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 11:29:27 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX Message-ID: Please review the following change: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ This changes the value returned by OSThread::thread_id() and os::current_thread_id() on macosx to return the mach thread_t instead of pthread_t. There is a separate method OSThread:pthread_id() that returns the pthread_t. The reason for this change is both that JFR would like a 4 byte value for thread id, and that SA requires access to the thread_t. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120215/ab82e96d/attachment.html From keith.mcguigan at oracle.com Wed Feb 15 03:33:01 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 15 Feb 2012 06:33:01 -0500 Subject: Request for code review (smallest review ever) In-Reply-To: <4F3B5FF1.9020604@oracle.com> References: <4F3AD030.6070408@oracle.com> <4F3B5FF1.9020604@oracle.com> Message-ID: <4F3B97ED.4070107@oracle.com> On 2/15/2012 2:34 AM, David Holmes wrote: > On 15/02/2012 7:20 AM, keith mcguigan wrote: >> >> Well, ok, I guess it's not the smallest code change -- I think I've >> matched this before -- but I guarantee you won't see one smaller than >> this! >> >> It's a one-liner (a one-character-er) to accept 0 as a successful return >> from an ioctl() call, for registering dtrace providers. >> >> http://cr.openjdk.java.net/~kamg/7145589/webrev.00/ > > Have to ask - why have we not noticed this before? No test coverage? Not really sure. I suspect testing missed this somehow, but there are scenarios where this would work fine. Basically, this would fail only when the JSDT provider was the very first dtrace provider registered with the system for the current process. In the past, the JVM probes were registered automatically at load time, so any JSDT providers were not "first". When the JVM probes were switched to lazy loading (a relatively recent change), this opened the door for this error. Similarly, if any loaded library loaded probes before trying to create the JSDT provider, that would also mask this bug. So it's possible that this was somehow hidden from our testing configurations. -- - Keith From nils.loodin at oracle.com Wed Feb 15 03:37:17 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 15 Feb 2012 12:37:17 +0100 Subject: Fwd: Diagnostic command fixes References: Message-ID: Forgot to reply all.. /Nisse Begin forwarded message: > From: Nils Loodin > Subject: Re: Diagnostic command fixes > Date: February 15, 2012 12:27:19 GMT+01:00 > To: David Holmes > > > On Feb 15, 2012, at 4:03 , David Holmes wrote: > >> Hi Nils, >> >> I only glanced at this and though the change in thread.cpp a little strange: >> >> 3401 // Set flag that basic initialization has completed. Used by exceptions and various >> 3402 // debug stuff, that does not work until all basic classes have been initialized. >> 3403 set_init_completed(); >> 3404 >> 3405 #ifndef USDT2 >> 3406 HS_DTRACE_PROBE(hotspot, vm__init__end); >> 3407 #else /* USDT2 */ >> 3408 HOTSPOT_VM_INIT_END(); >> 3409 #endif /* USDT2 */ >> 3410 >> 3411 // Must be run after init_ft which initializes ft_enabled >> 3412 if (TRACE_INITIALIZE() != JNI_OK) { >> 3413 vm_exit_during_initialization("Failed to initialize tracing backend"); >> 3414 } >> >> Seems odd to move something that can abort VM initialization to _after_ the point where we have set_init_completed() and posted vm__init__end. Surely this should go above there. >> > Yes, that would be odd. Moved it. > >> Also are we certain that none of the preceding initialization code will lead to other TRACE related code that will require that TRACE has already been initialized? (I seem to recall from sideband email that this had to move until after IllegalArgumentException had been initialized incase initialization failed). > Looked through it and didn't see anything. > >> >> Speaking of initializing IllegalArgumentException ... the else clause for InitializeJavaLangExceptionsErrors seems to be getting out of sync with the if clause. That said I wonder if anything can even work if InitializeJavaLangExceptionsErrors were set false? > I added IllegalArgumentException here. > >> >> Cheers, >> David > > Regards, > Nils >> >> On 14/02/2012 7:58 AM, Nils Loodin wrote: >>> Hey all! >>> >>> The new diagnostic command parser needs some additional specializations for time and bytes, here included. >>> Also a few fixes for crashes for some combinations of commandlines. >>> >>> Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. >>> >>> http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ >>> >>> I would also need a sponsor to get this in.. >>> >>> Regards >>> Nils Loodin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120215/4ffee633/attachment-0001.html From nils.loodin at oracle.com Wed Feb 15 03:38:40 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Wed, 15 Feb 2012 12:38:40 +0100 Subject: Diagnostic command fixes In-Reply-To: <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> Message-ID: <46E9FB0C-FDF7-43C1-B6CE-25F57BF32A53@oracle.com> Thank you all for suggesting even more improvements! Updated the webrev and put it here: http://cr.openjdk.java.net/~nloodin/7145243/webrev.02/ Regards, Nils Loodin On Feb 14, 2012, at 18:29 , Nils Loodin wrote: > Thanks all for suggestions on improvements. > I have an updated webrev here: > http://cr.openjdk.java.net/~nloodin/7145243/webrev.01/ > > Regards > Nils Loodin > > PS: Note - Frederic Parain has graciously taken upon himself to sponsor this. Many thanks! > > DS > > On Feb 13, 2012, at 22:58 , Nils Loodin wrote: > >> Hey all! >> >> The new diagnostic command parser needs some additional specializations for time and bytes, here included. >> Also a few fixes for crashes for some combinations of commandlines. >> >> Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. >> >> http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ >> >> I would also need a sponsor to get this in.. >> >> Regards >> Nils Loodin > From david.holmes at oracle.com Wed Feb 15 03:52:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2012 21:52:47 +1000 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: References: Message-ID: <4F3B9C8F.8080708@oracle.com> Hi Staffan, Not directly related to the change but what does _ALLBSD_SOURCE signify? In os_bsd.cpp: In os::thread_cpu_time the type of mach_thread has changed from mach_port_t to thread_t, but mach_thread is still passed into thread_info(). I expect they are both simple integral types, but I would expect that later gcc compilers might complain about this. What type does thread_info expect? Otherwise seems ok. David On 15/02/2012 8:29 PM, Staffan Larsen wrote: > Please review the following change: > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 > > Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ > > This changes the value returned by OSThread::thread_id() and > os::current_thread_id() on macosx to return the mach thread_t instead of > pthread_t. There is a separate method OSThread:pthread_id() that returns > the pthread_t. > > The reason for this change is both that JFR would like a 4 byte value > for thread id, and that SA requires access to the thread_t. > > Thanks, > /Staffan From sean.mullan at oracle.com Wed Feb 15 05:02:08 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 15 Feb 2012 13:02:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120215130235.9079D474EA@hg.openjdk.java.net> Changeset: 0720542d6c1e Author: mullan Date: 2012-02-15 07:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0720542d6c1e 7024604: OID.1 causes IAE in X500Principal constructor Reviewed-by: vinnie ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/auth/x500/package.html ! test/javax/security/auth/x500/X500Principal/Parse.java Changeset: 3207b3e271f2 Author: mullan Date: 2012-02-15 07:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3207b3e271f2 Merge From karen.kinnear at oracle.com Wed Feb 15 05:14:23 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 15 Feb 2012 08:14:23 -0500 Subject: Diagnostic command fixes In-Reply-To: <46E9FB0C-FDF7-43C1-B6CE-25F57BF32A53@oracle.com> References: <2F0B8C29-D921-4A1B-A3E1-A37C8067DB91@oracle.com> <18C2B832-5345-43F4-92DA-49BC27449A0C@oracle.com> <46E9FB0C-FDF7-43C1-B6CE-25F57BF32A53@oracle.com> Message-ID: <8519DA15-A6EB-453C-8E8F-536370B1B16F@oracle.com> Looks good. Thank you. And I will deal with the early event work when we add more events in terms of exactly how early we need to initialize the tracing subsystem. thanks, Karen On Feb 15, 2012, at 6:38 AM, Nils Loodin wrote: > Thank you all for suggesting even more improvements! > > Updated the webrev and put it here: > http://cr.openjdk.java.net/~nloodin/7145243/webrev.02/ > > Regards, > Nils Loodin > > On Feb 14, 2012, at 18:29 , Nils Loodin wrote: > >> Thanks all for suggestions on improvements. >> I have an updated webrev here: >> http://cr.openjdk.java.net/~nloodin/7145243/webrev.01/ >> >> Regards >> Nils Loodin >> >> PS: Note - Frederic Parain has graciously taken upon himself to sponsor this. Many thanks! >> >> DS >> >> On Feb 13, 2012, at 22:58 , Nils Loodin wrote: >> >>> Hey all! >>> >>> The new diagnostic command parser needs some additional specializations for time and bytes, here included. >>> Also a few fixes for crashes for some combinations of commandlines. >>> >>> Tested by throwing a lot of different arguments on the parser, also by running the tests in sun/tools/jcmd. >>> >>> http://cr.openjdk.java.net/~nloodin/7145243/webrev.00/ >>> >>> I would also need a sponsor to get this in.. >>> >>> Regards >>> Nils Loodin >> > From mikael.gerdin at oracle.com Wed Feb 15 05:57:05 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 15 Feb 2012 14:57:05 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: References: Message-ID: <4F3BB9B1.5020505@oracle.com> Hi Staffan, It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. /Mikael On 2012-02-15 11:29, Staffan Larsen wrote: > Please review the following change: > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 > > Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ > > This changes the value returned by OSThread::thread_id() and > os::current_thread_id() on macosx to return the mach thread_t instead of > pthread_t. There is a separate method OSThread:pthread_id() that returns > the pthread_t. > > The reason for this change is both that JFR would like a 4 byte value > for thread id, and that SA requires access to the thread_t. > > Thanks, > /Staffan From daniel.daugherty at oracle.com Wed Feb 15 07:16:34 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Feb 2012 08:16:34 -0700 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BB9B1.5020505@oracle.com> References: <4F3BB9B1.5020505@oracle.com> Message-ID: <4F3BCC52.8020703@oracle.com> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. It is used to identify code specific to the BSD family of OSes. The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to identify code specific to MacOS X. Typically you'll see something like: #ifdef _ALLBSD_SOURCE #ifdef __APPLE__ #else #endif // __APPLE__ #endif // _ALLBSD_SOURCE As for building on non-MacOS X BSDs, that would be nice, but we don't have the infrastructure to do it. Dan On 2/15/12 6:57 AM, Mikael Gerdin wrote: > Hi Staffan, > > It looks like you're adding Mac-specific stuff like thread_t and calls > to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure > this won't break BSD builds? > Does the OSX compiler define _ALLBSD_SOURCE or is that for > (free|net|open)bsd? > It's too bad we don't do regular builds on any of the BSDs, otherwise > this would have been easier to figure out. > > /Mikael > > > On 2012-02-15 11:29, Staffan Larsen wrote: >> Please review the following change: >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >> >> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >> >> This changes the value returned by OSThread::thread_id() and >> os::current_thread_id() on macosx to return the mach thread_t instead of >> pthread_t. There is a separate method OSThread:pthread_id() that returns >> the pthread_t. >> >> The reason for this change is both that JFR would like a 4 byte value >> for thread id, and that SA requires access to the thread_t. >> >> Thanks, >> /Staffan > From yumin.qi at sun.com Wed Feb 15 09:21:48 2012 From: yumin.qi at sun.com (yumin.qi at sun.com) Date: Wed, 15 Feb 2012 17:21:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20120215172157.0437A474F1@hg.openjdk.java.net> Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/64fc5ac1b770 Merge From frederic.parain at oracle.com Wed Feb 15 09:29:42 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 17:29:42 +0000 Subject: hg: jdk8/tl/jdk: 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Message-ID: <20120215173008.2669A474F4@hg.openjdk.java.net> Changeset: 59884f656b7d Author: fparain Date: 2012-02-15 09:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59884f656b7d 7144833: sun/tools/jcmd/jcmd-Defaults.sh failing intermittently Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/tools/jcmd/jcmd_Output1.awk From alan.bateman at oracle.com Wed Feb 15 09:33:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 15 Feb 2012 17:33:14 +0000 Subject: hg: jdk8/tl/jaxws: 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds) Message-ID: <20120215173314.75D1F474F5@hg.openjdk.java.net> Changeset: b962e9c3eba2 Author: alanb Date: 2012-02-15 17:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b962e9c3eba2 7145910: Remove dependency on apt and com.sun.mirror API (breaks boot cycle builds) Reviewed-by: ohair ! jaxws.properties From paul.hohensee at oracle.com Wed Feb 15 10:33:55 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 15 Feb 2012 13:33:55 -0500 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BCC52.8020703@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> Message-ID: <4F3BFA93.5000003@oracle.com> Imo we should at least try to make non-osx bsd builds work, since the original code did work for non-osx builds. This change doesn't do that. In globalDefinitions_gcc.hpp, if you keep the lines #undef ELF_AC #undef EFL_ID then you don't have to change vm_version_x86.hpp. Paul On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: > The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile > infrastructure. > It is used to identify code specific to the BSD family of OSes. > The __APPLE__ symbol is defined by the Apple compiler(s) and it is > used to > identify code specific to MacOS X. > > Typically you'll see something like: > > #ifdef _ALLBSD_SOURCE > > > > #ifdef __APPLE__ > > #else > > #endif // __APPLE__ > #endif // _ALLBSD_SOURCE > > As for building on non-MacOS X BSDs, that would be nice, but we > don't have the infrastructure to do it. > > Dan > > On 2/15/12 6:57 AM, Mikael Gerdin wrote: >> Hi Staffan, >> >> It looks like you're adding Mac-specific stuff like thread_t and >> calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you >> sure this won't break BSD builds? >> Does the OSX compiler define _ALLBSD_SOURCE or is that for >> (free|net|open)bsd? >> It's too bad we don't do regular builds on any of the BSDs, otherwise >> this would have been easier to figure out. >> >> /Mikael >> >> >> On 2012-02-15 11:29, Staffan Larsen wrote: >>> Please review the following change: >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>> >>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>> >>> This changes the value returned by OSThread::thread_id() and >>> os::current_thread_id() on macosx to return the mach thread_t >>> instead of >>> pthread_t. There is a separate method OSThread:pthread_id() that >>> returns >>> the pthread_t. >>> >>> The reason for this change is both that JFR would like a 4 byte value >>> for thread id, and that SA requires access to the thread_t. >>> >>> Thanks, >>> /Staffan >> From frederic.parain at oracle.com Wed Feb 15 10:47:40 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 15 Feb 2012 18:47:40 +0000 Subject: hg: jdk8/tl/jdk: 7145925: Removing remote access to diagnostic commands in the HotSpotDiagnosticMBean Message-ID: <20120215184750.89476474F9@hg.openjdk.java.net> Changeset: 20d39a0e6fdc Author: fparain Date: 2012-02-15 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20d39a0e6fdc 7145925: Removing remote access to diagnostic commands in the HotSpotDiagnosticMBean Reviewed-by: acorn, mchung, phh ! make/java/management/mapfile-vers - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java From paul.hohensee at oracle.com Wed Feb 15 10:49:07 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 15 Feb 2012 13:49:07 -0500 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BFA93.5000003@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> Message-ID: <4F3BFE23.5010602@oracle.com> Also, You can move the #include of mach.h into globalDefinitions_gcc.hpp, in the #ifdef __APPLE__ section. That way, it won't cause a compile- time error on non-osx platforms that don't have it. The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp can be put under a #ifdef __APPLE__, vis., #ifdef _ALLBSD_SOURCE #ifdef __APPLE__ thread_t _thread_id; #else pthread_t _thread_id; #endif #endif The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. If there's a thread_t defined by non-osx bsd implementations, then you don't need predication in os_bsd.hpp, though you'd still need it in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx bsd platforms. Thanks, Paul On 2/15/12 1:33 PM, Paul Hohensee wrote: > Imo we should at least try to make non-osx bsd builds work, since > the original code did work for non-osx builds. This change doesn't > do that. > > In globalDefinitions_gcc.hpp, if you keep the lines > > #undef ELF_AC > #undef EFL_ID > > then you don't have to change vm_version_x86.hpp. > > Paul > > On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile >> infrastructure. >> It is used to identify code specific to the BSD family of OSes. >> The __APPLE__ symbol is defined by the Apple compiler(s) and it is >> used to >> identify code specific to MacOS X. >> >> Typically you'll see something like: >> >> #ifdef _ALLBSD_SOURCE >> >> >> >> #ifdef __APPLE__ >> >> #else >> >> #endif // __APPLE__ >> #endif // _ALLBSD_SOURCE >> >> As for building on non-MacOS X BSDs, that would be nice, but we >> don't have the infrastructure to do it. >> >> Dan >> >> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>> Hi Staffan, >>> >>> It looks like you're adding Mac-specific stuff like thread_t and >>> calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you >>> sure this won't break BSD builds? >>> Does the OSX compiler define _ALLBSD_SOURCE or is that for >>> (free|net|open)bsd? >>> It's too bad we don't do regular builds on any of the BSDs, >>> otherwise this would have been easier to figure out. >>> >>> /Mikael >>> >>> >>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>> Please review the following change: >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>> >>>> This changes the value returned by OSThread::thread_id() and >>>> os::current_thread_id() on macosx to return the mach thread_t >>>> instead of >>>> pthread_t. There is a separate method OSThread:pthread_id() that >>>> returns >>>> the pthread_t. >>>> >>>> The reason for this change is both that JFR would like a 4 byte value >>>> for thread id, and that SA requires access to the thread_t. >>>> >>>> Thanks, >>>> /Staffan >>> From staffan.larsen at oracle.com Wed Feb 15 10:52:19 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 19:52:19 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3B9C8F.8080708@oracle.com> References: <4F3B9C8F.8080708@oracle.com> Message-ID: <0DFAA35A-7494-4230-B4B6-48CB53C21E39@oracle.com> On 15 feb 2012, at 12:52, David Holmes wrote: > Hi Staffan, > > Not directly related to the change but what does _ALLBSD_SOURCE signify? What Dan said (I wasn't sure myself). > In os_bsd.cpp: > > In os::thread_cpu_time the type of mach_thread has changed from mach_port_t to thread_t, but mach_thread is still passed into thread_info(). I expect they are both simple integral types, but I would expect that later gcc compilers might complain about this. What type does thread_info expect? thread_info() expects a thread_t, but thread_t and mach_port_t are actually the same thing (typdef:ed). > > Otherwise seems ok. Thanks, /Staffan > > David > > > On 15/02/2012 8:29 PM, Staffan Larsen wrote: >> Please review the following change: >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >> >> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >> >> This changes the value returned by OSThread::thread_id() and >> os::current_thread_id() on macosx to return the mach thread_t instead of >> pthread_t. There is a separate method OSThread:pthread_id() that returns >> the pthread_t. >> >> The reason for this change is both that JFR would like a 4 byte value >> for thread id, and that SA requires access to the thread_t. >> >> Thanks, >> /Staffan From staffan.larsen at oracle.com Wed Feb 15 10:53:32 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 19:53:32 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BB9B1.5020505@oracle.com> References: <4F3BB9B1.5020505@oracle.com> Message-ID: <4563967C-DC7C-47D7-AECC-0F391DA036A0@oracle.com> Unfortunately I can't verify if other bsd builds fail as we have none at our disposal. /Staffan On 15 feb 2012, at 14:57, Mikael Gerdin wrote: > Hi Staffan, > > It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? > Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? > It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. > > /Mikael > > > On 2012-02-15 11:29, Staffan Larsen wrote: >> Please review the following change: >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >> >> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >> >> This changes the value returned by OSThread::thread_id() and >> os::current_thread_id() on macosx to return the mach thread_t instead of >> pthread_t. There is a separate method OSThread:pthread_id() that returns >> the pthread_t. >> >> The reason for this change is both that JFR would like a 4 byte value >> for thread id, and that SA requires access to the thread_t. >> >> Thanks, >> /Staffan > From staffan.larsen at oracle.com Wed Feb 15 10:56:21 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 19:56:21 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BFA93.5000003@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> Message-ID: On 15 feb 2012, at 19:33, Paul Hohensee wrote: > Imo we should at least try to make non-osx bsd builds work, since > the original code did work for non-osx builds. This change doesn't > do that. > > In globalDefinitions_gcc.hpp, if you keep the lines > > #undef ELF_AC > #undef EFL_ID > > then you don't have to change vm_version_x86.hpp. The problem was that my additional include of mach/mach.h in os_bsd.inline.hpp brought back those defines. So I went with Tom's suggestion and renamed the flags in vm_version_x86.hpp. /Staffan > > Paul > > On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >> It is used to identify code specific to the BSD family of OSes. >> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >> identify code specific to MacOS X. >> >> Typically you'll see something like: >> >> #ifdef _ALLBSD_SOURCE >> >> >> >> #ifdef __APPLE__ >> >> #else >> >> #endif // __APPLE__ >> #endif // _ALLBSD_SOURCE >> >> As for building on non-MacOS X BSDs, that would be nice, but we >> don't have the infrastructure to do it. >> >> Dan >> >> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>> Hi Staffan, >>> >>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>> >>> /Mikael >>> >>> >>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>> Please review the following change: >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>> >>>> This changes the value returned by OSThread::thread_id() and >>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>> the pthread_t. >>>> >>>> The reason for this change is both that JFR would like a 4 byte value >>>> for thread id, and that SA requires access to the thread_t. >>>> >>>> Thanks, >>>> /Staffan >>> From staffan.larsen at oracle.com Wed Feb 15 10:58:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 19:58:52 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BFE23.5010602@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> Message-ID: <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> On 15 feb 2012, at 19:49, Paul Hohensee wrote: > Also, > > You can move the #include of mach.h into globalDefinitions_gcc.hpp, > in the #ifdef __APPLE__ section. That way, it won't cause a compile- > time error on non-osx platforms that don't have it. I dislike adding more stuff to globalDefinitions since that gets pulled in all over the place. I'd prefer to have #includes only where they are needed. > The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp > can be put under a #ifdef __APPLE__, vis., > > #ifdef _ALLBSD_SOURCE > #ifdef __APPLE__ > thread_t _thread_id; > #else > pthread_t _thread_id; > #endif > #endif > > The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. > > If there's a thread_t defined by non-osx bsd implementations, then > you don't need predication in os_bsd.hpp, though you'd still need it > in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx > bsd platforms. I could do that, but the question is how much work we should put into not trying to break something that we can't test anyway. There's no way, even if I do this that I can verify that it works. /Staffan > > Thanks, > > Paul > > On 2/15/12 1:33 PM, Paul Hohensee wrote: >> Imo we should at least try to make non-osx bsd builds work, since >> the original code did work for non-osx builds. This change doesn't >> do that. >> >> In globalDefinitions_gcc.hpp, if you keep the lines >> >> #undef ELF_AC >> #undef EFL_ID >> >> then you don't have to change vm_version_x86.hpp. >> >> Paul >> >> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>> It is used to identify code specific to the BSD family of OSes. >>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>> identify code specific to MacOS X. >>> >>> Typically you'll see something like: >>> >>> #ifdef _ALLBSD_SOURCE >>> >>> >>> >>> #ifdef __APPLE__ >>> >>> #else >>> >>> #endif // __APPLE__ >>> #endif // _ALLBSD_SOURCE >>> >>> As for building on non-MacOS X BSDs, that would be nice, but we >>> don't have the infrastructure to do it. >>> >>> Dan >>> >>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>> Hi Staffan, >>>> >>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>> >>>> /Mikael >>>> >>>> >>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>> Please review the following change: >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>> >>>>> This changes the value returned by OSThread::thread_id() and >>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>> the pthread_t. >>>>> >>>>> The reason for this change is both that JFR would like a 4 byte value >>>>> for thread id, and that SA requires access to the thread_t. >>>>> >>>>> Thanks, >>>>> /Staffan >>>> From paul.hohensee at oracle.com Wed Feb 15 11:00:01 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 15 Feb 2012 14:00:01 -0500 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> Message-ID: <4F3C00B1.2080205@oracle.com> Right. If you move the #include of mach.h from os_bsd.inline.hpp into globalDefinitions_gcc.hpp and #undef EFL_AC and EFL_ID in globalDefinitions_gcc.hpp, then the problem goes away. Paul On 2/15/12 1:56 PM, Staffan Larsen wrote: > On 15 feb 2012, at 19:33, Paul Hohensee wrote: > >> Imo we should at least try to make non-osx bsd builds work, since >> the original code did work for non-osx builds. This change doesn't >> do that. >> >> In globalDefinitions_gcc.hpp, if you keep the lines >> >> #undef ELF_AC >> #undef EFL_ID >> >> then you don't have to change vm_version_x86.hpp. > The problem was that my additional include of mach/mach.h in os_bsd.inline.hpp brought back those defines. So I went with Tom's suggestion and renamed the flags in vm_version_x86.hpp. > > /Staffan > > >> Paul >> >> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>> It is used to identify code specific to the BSD family of OSes. >>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>> identify code specific to MacOS X. >>> >>> Typically you'll see something like: >>> >>> #ifdef _ALLBSD_SOURCE >>> >>> >>> >>> #ifdef __APPLE__ >>> >>> #else >>> >>> #endif // __APPLE__ >>> #endif // _ALLBSD_SOURCE >>> >>> As for building on non-MacOS X BSDs, that would be nice, but we >>> don't have the infrastructure to do it. >>> >>> Dan >>> >>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>> Hi Staffan, >>>> >>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>> >>>> /Mikael >>>> >>>> >>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>> Please review the following change: >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>> >>>>> This changes the value returned by OSThread::thread_id() and >>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>> the pthread_t. >>>>> >>>>> The reason for this change is both that JFR would like a 4 byte value >>>>> for thread id, and that SA requires access to the thread_t. >>>>> >>>>> Thanks, >>>>> /Staffan From paul.hohensee at oracle.com Wed Feb 15 11:03:36 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 15 Feb 2012 14:03:36 -0500 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> Message-ID: <4F3C0188.1070909@oracle.com> On 2/15/12 1:58 PM, Staffan Larsen wrote: > On 15 feb 2012, at 19:49, Paul Hohensee wrote: > >> Also, >> >> You can move the #include of mach.h into globalDefinitions_gcc.hpp, >> in the #ifdef __APPLE__ section. That way, it won't cause a compile- >> time error on non-osx platforms that don't have it. > I dislike adding more stuff to globalDefinitions since that gets pulled in all over the place. I'd prefer to have #includes only where they are needed. globalDefinitions_gcc.hpp is where these sorts of #includes currently live, so I'd go with present practice rather than doing something new. If you want to put the include of mach.h in os_bsd.inline.hpp, then you should do something similar with all the platform-dependent includes in globalDefinitions_gcc.hpp. > >> The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp >> can be put under a #ifdef __APPLE__, vis., >> >> #ifdef _ALLBSD_SOURCE >> #ifdef __APPLE__ >> thread_t _thread_id; >> #else >> pthread_t _thread_id; >> #endif >> #endif >> >> The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. >> >> If there's a thread_t defined by non-osx bsd implementations, then >> you don't need predication in os_bsd.hpp, though you'd still need it >> in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx >> bsd platforms. > I could do that, but the question is how much work we should put into not trying to break something that we can't test anyway. There's no way, even if I do this that I can verify that it works. Even so, if we ever need to make hotspot work on non-osx bsd platforms, we'll at least have markers to guide the work. Paul > > /Staffan > >> Thanks, >> >> Paul >> >> On 2/15/12 1:33 PM, Paul Hohensee wrote: >>> Imo we should at least try to make non-osx bsd builds work, since >>> the original code did work for non-osx builds. This change doesn't >>> do that. >>> >>> In globalDefinitions_gcc.hpp, if you keep the lines >>> >>> #undef ELF_AC >>> #undef EFL_ID >>> >>> then you don't have to change vm_version_x86.hpp. >>> >>> Paul >>> >>> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>> It is used to identify code specific to the BSD family of OSes. >>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>> identify code specific to MacOS X. >>>> >>>> Typically you'll see something like: >>>> >>>> #ifdef _ALLBSD_SOURCE >>>> >>>> >>>> >>>> #ifdef __APPLE__ >>>> >>>> #else >>>> >>>> #endif // __APPLE__ >>>> #endif // _ALLBSD_SOURCE >>>> >>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>> don't have the infrastructure to do it. >>>> >>>> Dan >>>> >>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>> Hi Staffan, >>>>> >>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>> >>>>> /Mikael >>>>> >>>>> >>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>> Please review the following change: >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>> >>>>>> This changes the value returned by OSThread::thread_id() and >>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>> the pthread_t. >>>>>> >>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>> for thread id, and that SA requires access to the thread_t. >>>>>> >>>>>> Thanks, >>>>>> /Staffan From staffan.larsen at oracle.com Wed Feb 15 11:25:06 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 20:25:06 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3C0188.1070909@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> <4F3C0188.1070909@oracle.com> Message-ID: On 15 feb 2012, at 20:03, Paul Hohensee wrote: > On 2/15/12 1:58 PM, Staffan Larsen wrote: >> On 15 feb 2012, at 19:49, Paul Hohensee wrote: >> >>> Also, >>> >>> You can move the #include of mach.h into globalDefinitions_gcc.hpp, >>> in the #ifdef __APPLE__ section. That way, it won't cause a compile- >>> time error on non-osx platforms that don't have it. >> I dislike adding more stuff to globalDefinitions since that gets pulled in all over the place. I'd prefer to have #includes only where they are needed. > > globalDefinitions_gcc.hpp is where these sorts of #includes currently live, > so I'd go with present practice rather than doing something new. If > you want to put the include of mach.h in os_bsd.inline.hpp, then you > should do something similar with all the platform-dependent includes > in globalDefinitions_gcc.hpp. I'd actually like to have it in osThread_bsd.hpp, but that isn't possible. I'll put in gloabalDefinitions_gcc.hpp. > >> >>> The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp >>> can be put under a #ifdef __APPLE__, vis., >>> >>> #ifdef _ALLBSD_SOURCE >>> #ifdef __APPLE__ >>> thread_t _thread_id; >>> #else >>> pthread_t _thread_id; >>> #endif >>> #endif >>> >>> The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. >>> >>> If there's a thread_t defined by non-osx bsd implementations, then >>> you don't need predication in os_bsd.hpp, though you'd still need it >>> in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx >>> bsd platforms. >> I could do that, but the question is how much work we should put into not trying to break something that we can't test anyway. There's no way, even if I do this that I can verify that it works. > > Even so, if we ever need to make hotspot work on non-osx bsd platforms, we'll > at least have markers to guide the work. OK - I'll try to fix things up. /Staffan > > Paul > >> >> /Staffan >> >>> Thanks, >>> >>> Paul >>> >>> On 2/15/12 1:33 PM, Paul Hohensee wrote: >>>> Imo we should at least try to make non-osx bsd builds work, since >>>> the original code did work for non-osx builds. This change doesn't >>>> do that. >>>> >>>> In globalDefinitions_gcc.hpp, if you keep the lines >>>> >>>> #undef ELF_AC >>>> #undef EFL_ID >>>> >>>> then you don't have to change vm_version_x86.hpp. >>>> >>>> Paul >>>> >>>> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>>> It is used to identify code specific to the BSD family of OSes. >>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>>> identify code specific to MacOS X. >>>>> >>>>> Typically you'll see something like: >>>>> >>>>> #ifdef _ALLBSD_SOURCE >>>>> >>>>> >>>>> >>>>> #ifdef __APPLE__ >>>>> >>>>> #else >>>>> >>>>> #endif // __APPLE__ >>>>> #endif // _ALLBSD_SOURCE >>>>> >>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>> don't have the infrastructure to do it. >>>>> >>>>> Dan >>>>> >>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>>> >>>>>> /Mikael >>>>>> >>>>>> >>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>> Please review the following change: >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>> >>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>>> the pthread_t. >>>>>>> >>>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan From staffan.larsen at oracle.com Wed Feb 15 11:30:35 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 20:30:35 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3BCC52.8020703@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> Message-ID: <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? /Staffan On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: > The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. > It is used to identify code specific to the BSD family of OSes. > The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to > identify code specific to MacOS X. > > Typically you'll see something like: > > #ifdef _ALLBSD_SOURCE > > > > #ifdef __APPLE__ > > #else > > #endif // __APPLE__ > #endif // _ALLBSD_SOURCE > > As for building on non-MacOS X BSDs, that would be nice, but we > don't have the infrastructure to do it. > > Dan > > On 2/15/12 6:57 AM, Mikael Gerdin wrote: >> Hi Staffan, >> >> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >> >> /Mikael >> >> >> On 2012-02-15 11:29, Staffan Larsen wrote: >>> Please review the following change: >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>> >>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>> >>> This changes the value returned by OSThread::thread_id() and >>> os::current_thread_id() on macosx to return the mach thread_t instead of >>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>> the pthread_t. >>> >>> The reason for this change is both that JFR would like a 4 byte value >>> for thread id, and that SA requires access to the thread_t. >>> >>> Thanks, >>> /Staffan >> From paul.hohensee at oracle.com Wed Feb 15 11:40:07 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 15 Feb 2012 14:40:07 -0500 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> <4F3C0188.1070909@oracle.com> Message-ID: <4F3C0A17.9060403@oracle.com> Thanks! Paul On 2/15/12 2:25 PM, Staffan Larsen wrote: > On 15 feb 2012, at 20:03, Paul Hohensee wrote: > >> On 2/15/12 1:58 PM, Staffan Larsen wrote: >>> On 15 feb 2012, at 19:49, Paul Hohensee wrote: >>> >>>> Also, >>>> >>>> You can move the #include of mach.h into globalDefinitions_gcc.hpp, >>>> in the #ifdef __APPLE__ section. That way, it won't cause a compile- >>>> time error on non-osx platforms that don't have it. >>> I dislike adding more stuff to globalDefinitions since that gets pulled in all over the place. I'd prefer to have #includes only where they are needed. >> globalDefinitions_gcc.hpp is where these sorts of #includes currently live, >> so I'd go with present practice rather than doing something new. If >> you want to put the include of mach.h in os_bsd.inline.hpp, then you >> should do something similar with all the platform-dependent includes >> in globalDefinitions_gcc.hpp. > I'd actually like to have it in osThread_bsd.hpp, but that isn't possible. I'll put in gloabalDefinitions_gcc.hpp. > > >>>> The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp >>>> can be put under a #ifdef __APPLE__, vis., >>>> >>>> #ifdef _ALLBSD_SOURCE >>>> #ifdef __APPLE__ >>>> thread_t _thread_id; >>>> #else >>>> pthread_t _thread_id; >>>> #endif >>>> #endif >>>> >>>> The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. >>>> >>>> If there's a thread_t defined by non-osx bsd implementations, then >>>> you don't need predication in os_bsd.hpp, though you'd still need it >>>> in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx >>>> bsd platforms. >>> I could do that, but the question is how much work we should put into not trying to break something that we can't test anyway. There's no way, even if I do this that I can verify that it works. >> Even so, if we ever need to make hotspot work on non-osx bsd platforms, we'll >> at least have markers to guide the work. > OK - I'll try to fix things up. > > /Staffan > >> Paul >> >>> /Staffan >>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> On 2/15/12 1:33 PM, Paul Hohensee wrote: >>>>> Imo we should at least try to make non-osx bsd builds work, since >>>>> the original code did work for non-osx builds. This change doesn't >>>>> do that. >>>>> >>>>> In globalDefinitions_gcc.hpp, if you keep the lines >>>>> >>>>> #undef ELF_AC >>>>> #undef EFL_ID >>>>> >>>>> then you don't have to change vm_version_x86.hpp. >>>>> >>>>> Paul >>>>> >>>>> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>>>> It is used to identify code specific to the BSD family of OSes. >>>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>>>> identify code specific to MacOS X. >>>>>> >>>>>> Typically you'll see something like: >>>>>> >>>>>> #ifdef _ALLBSD_SOURCE >>>>>> >>>>>> >>>>>> >>>>>> #ifdef __APPLE__ >>>>>> >>>>>> #else >>>>>> >>>>>> #endif // __APPLE__ >>>>>> #endif // _ALLBSD_SOURCE >>>>>> >>>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>>> don't have the infrastructure to do it. >>>>>> >>>>>> Dan >>>>>> >>>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>> >>>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>>> Please review the following change: >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>>> >>>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>>>> the pthread_t. >>>>>>>> >>>>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan From daniel.daugherty at oracle.com Wed Feb 15 12:24:21 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Feb 2012 13:24:21 -0700 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> Message-ID: <4F3C1475.1090907@oracle.com> The src/os/bsd code was derived from the src/os/linux code. #ifdef _ALLBSD_SOURCE was used to flag (most) changes relative to Linux for the BSD port. The #ifdef'ing is not perfect because the Linux code also evolved as the BSD port was being done and also because sometimes folks forgot to #ifdef their changes... Eventually, there is supposed to be a rework/rewrite in this area where all the "nixes" share code. It won't be under src/os/posix, but we'll think of some good name if the project ever gets done... Dan On 2/15/12 12:30 PM, Staffan Larsen wrote: > Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? > > /Staffan > > > On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: > >> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >> It is used to identify code specific to the BSD family of OSes. >> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >> identify code specific to MacOS X. >> >> Typically you'll see something like: >> >> #ifdef _ALLBSD_SOURCE >> >> >> >> #ifdef __APPLE__ >> >> #else >> >> #endif // __APPLE__ >> #endif // _ALLBSD_SOURCE >> >> As for building on non-MacOS X BSDs, that would be nice, but we >> don't have the infrastructure to do it. >> >> Dan >> >> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>> Hi Staffan, >>> >>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>> >>> /Mikael >>> >>> >>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>> Please review the following change: >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>> >>>> This changes the value returned by OSThread::thread_id() and >>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>> the pthread_t. >>>> >>>> The reason for this change is both that JFR would like a 4 byte value >>>> for thread id, and that SA requires access to the thread_t. >>>> >>>> Thanks, >>>> /Staffan From staffan.larsen at oracle.com Wed Feb 15 12:34:13 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Feb 2012 21:34:13 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3C1475.1090907@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> <4F3C1475.1090907@oracle.com> Message-ID: <67A9EBEA-B827-4971-8B4E-EE08980DF5D3@oracle.com> That's what I guessed. So essentially all the code the is in the #else part of #ifdef _ALLBSD_SOURCE under src/os/bsd can be removed and the #ifdef _ALLBSD_SOURCE can be skipped. Like so: #ifdef _ALLBSD_SOURCE xxx; #else yyy; #endif can be changed to: xxx; I'll volunteer to do that cleanup. /Staffan On 15 feb 2012, at 21:24, Daniel D. Daugherty wrote: > The src/os/bsd code was derived from the src/os/linux code. > #ifdef _ALLBSD_SOURCE was used to flag (most) changes relative > to Linux for the BSD port. The #ifdef'ing is not perfect because > the Linux code also evolved as the BSD port was being done and > also because sometimes folks forgot to #ifdef their changes... > > Eventually, there is supposed to be a rework/rewrite in this area > where all the "nixes" share code. It won't be under src/os/posix, > but we'll think of some good name if the project ever gets done... > > Dan > > > On 2/15/12 12:30 PM, Staffan Larsen wrote: >> Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? >> >> /Staffan >> >> >> On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: >> >>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>> It is used to identify code specific to the BSD family of OSes. >>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>> identify code specific to MacOS X. >>> >>> Typically you'll see something like: >>> >>> #ifdef _ALLBSD_SOURCE >>> >>> >>> >>> #ifdef __APPLE__ >>> >>> #else >>> >>> #endif // __APPLE__ >>> #endif // _ALLBSD_SOURCE >>> >>> As for building on non-MacOS X BSDs, that would be nice, but we >>> don't have the infrastructure to do it. >>> >>> Dan >>> >>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>> Hi Staffan, >>>> >>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>> >>>> /Mikael >>>> >>>> >>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>> Please review the following change: >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>> >>>>> This changes the value returned by OSThread::thread_id() and >>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>> the pthread_t. >>>>> >>>>> The reason for this change is both that JFR would like a 4 byte value >>>>> for thread id, and that SA requires access to the thread_t. >>>>> >>>>> Thanks, >>>>> /Staffan From daniel.daugherty at oracle.com Wed Feb 15 12:46:50 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Feb 2012 13:46:50 -0700 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <67A9EBEA-B827-4971-8B4E-EE08980DF5D3@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> <4F3C1475.1090907@oracle.com> <67A9EBEA-B827-4971-8B4E-EE08980DF5D3@oracle.com> Message-ID: <4F3C19BA.3010901@oracle.com> On 2/15/12 1:34 PM, Staffan Larsen wrote: > That's what I guessed. So essentially all the code the is in the #else part of #ifdef _ALLBSD_SOURCE under src/os/bsd can be removed and the #ifdef _ALLBSD_SOURCE can be skipped. Like so: > > #ifdef _ALLBSD_SOURCE > xxx; > #else > yyy; > #endif > > can be changed to: > > xxx; > > I'll volunteer to do that cleanup. I think that would make the eventual merge of all the "nixes" more difficult... Dan > /Staffan > > On 15 feb 2012, at 21:24, Daniel D. Daugherty wrote: > >> The src/os/bsd code was derived from the src/os/linux code. >> #ifdef _ALLBSD_SOURCE was used to flag (most) changes relative >> to Linux for the BSD port. The #ifdef'ing is not perfect because >> the Linux code also evolved as the BSD port was being done and >> also because sometimes folks forgot to #ifdef their changes... >> >> Eventually, there is supposed to be a rework/rewrite in this area >> where all the "nixes" share code. It won't be under src/os/posix, >> but we'll think of some good name if the project ever gets done... >> >> Dan >> >> >> On 2/15/12 12:30 PM, Staffan Larsen wrote: >>> Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? >>> >>> /Staffan >>> >>> >>> On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: >>> >>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>> It is used to identify code specific to the BSD family of OSes. >>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>> identify code specific to MacOS X. >>>> >>>> Typically you'll see something like: >>>> >>>> #ifdef _ALLBSD_SOURCE >>>> >>>> >>>> >>>> #ifdef __APPLE__ >>>> >>>> #else >>>> >>>> #endif // __APPLE__ >>>> #endif // _ALLBSD_SOURCE >>>> >>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>> don't have the infrastructure to do it. >>>> >>>> Dan >>>> >>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>> Hi Staffan, >>>>> >>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>> >>>>> /Mikael >>>>> >>>>> >>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>> Please review the following change: >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>> >>>>>> This changes the value returned by OSThread::thread_id() and >>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>> the pthread_t. >>>>>> >>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>> for thread id, and that SA requires access to the thread_t. >>>>>> >>>>>> Thanks, >>>>>> /Staffan From frederic.parain at oracle.com Wed Feb 15 16:07:14 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 16 Feb 2012 00:07:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7145243: Need additional specializations for argument parsing framework Message-ID: <20120216000719.0B0464750C@hg.openjdk.java.net> Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp From xuelei.fan at oracle.com Wed Feb 15 23:55:16 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 16 Feb 2012 07:55:16 +0000 Subject: hg: jdk8/tl/jdk: 7145837: a little performance improvement on the usage of SecureRandom Message-ID: <20120216075542.114C147516@hg.openjdk.java.net> Changeset: 45804d661008 Author: xuelei Date: 2012-02-15 23:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45804d661008 7145837: a little performance improvement on the usage of SecureRandom Reviewed-by: chegar, wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java From staffan.larsen at oracle.com Thu Feb 16 01:15:03 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 16 Feb 2012 10:15:03 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3C19BA.3010901@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> <4F3C1475.1090907@oracle.com> <67A9EBEA-B827-4971-8B4E-EE08980DF5D3@oracle.com> <4F3C19BA.3010901@oracle.com> Message-ID: <2D1564B2-F915-492F-91C3-85C2F5780E8E@oracle.com> It does make the current code very hard to read: #ifdef _ALLBSD_SOURCE #ifdef __APPLE__ thread_t _thread_id; #else pthread_t _thread_id; #endif pthread_t _pthread_id; #else // _thread_id is kernel thread id (similar to LWP id on Solaris). Each // thread has a unique thread_id (BsdThreads or NPTL). It can be used // to access /proc. pid_t _thread_id; // _pthread_id is the pthread id, which is used by library calls // (e.g. pthread_kill). pthread_t _pthread_id; #endif I think running a visual diff of the linux and bsd files will give you a simpler (and more accurate) starting point for an eventual merge. /Staffan On 15 feb 2012, at 21:46, Daniel D. Daugherty wrote: > On 2/15/12 1:34 PM, Staffan Larsen wrote: >> That's what I guessed. So essentially all the code the is in the #else part of #ifdef _ALLBSD_SOURCE under src/os/bsd can be removed and the #ifdef _ALLBSD_SOURCE can be skipped. Like so: >> >> #ifdef _ALLBSD_SOURCE >> xxx; >> #else >> yyy; >> #endif >> >> can be changed to: >> >> xxx; >> >> I'll volunteer to do that cleanup. > > I think that would make the eventual merge of all the "nixes" > more difficult... > > Dan > > >> /Staffan >> >> On 15 feb 2012, at 21:24, Daniel D. Daugherty wrote: >> >>> The src/os/bsd code was derived from the src/os/linux code. >>> #ifdef _ALLBSD_SOURCE was used to flag (most) changes relative >>> to Linux for the BSD port. The #ifdef'ing is not perfect because >>> the Linux code also evolved as the BSD port was being done and >>> also because sometimes folks forgot to #ifdef their changes... >>> >>> Eventually, there is supposed to be a rework/rewrite in this area >>> where all the "nixes" share code. It won't be under src/os/posix, >>> but we'll think of some good name if the project ever gets done... >>> >>> Dan >>> >>> >>> On 2/15/12 12:30 PM, Staffan Larsen wrote: >>>> Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? >>>> >>>> /Staffan >>>> >>>> >>>> On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: >>>> >>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>>> It is used to identify code specific to the BSD family of OSes. >>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>>> identify code specific to MacOS X. >>>>> >>>>> Typically you'll see something like: >>>>> >>>>> #ifdef _ALLBSD_SOURCE >>>>> >>>>> >>>>> >>>>> #ifdef __APPLE__ >>>>> >>>>> #else >>>>> >>>>> #endif // __APPLE__ >>>>> #endif // _ALLBSD_SOURCE >>>>> >>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>> don't have the infrastructure to do it. >>>>> >>>>> Dan >>>>> >>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>>> >>>>>> /Mikael >>>>>> >>>>>> >>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>> Please review the following change: >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>> >>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>>> the pthread_t. >>>>>>> >>>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan From nils.loodin at oracle.com Thu Feb 16 01:35:00 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 16 Feb 2012 10:35:00 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3C19BA.3010901@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <10DC282E-A322-49DA-9DC5-5A0B837BE0E8@oracle.com> <4F3C1475.1090907@oracle.com> <67A9EBEA-B827-4971-8B4E-EE08980DF5D3@oracle.com> <4F3C19BA.3010901@oracle.com> Message-ID: <7DA12EAF-33C3-4541-9419-8B4AEEBC14FA@oracle.com> Does that not count under your mail about premature optimizations then? :D /Nisse On Feb 15, 2012, at 21:46 , Daniel D. Daugherty wrote: > On 2/15/12 1:34 PM, Staffan Larsen wrote: >> That's what I guessed. So essentially all the code the is in the #else part of #ifdef _ALLBSD_SOURCE under src/os/bsd can be removed and the #ifdef _ALLBSD_SOURCE can be skipped. Like so: >> >> #ifdef _ALLBSD_SOURCE >> xxx; >> #else >> yyy; >> #endif >> >> can be changed to: >> >> xxx; >> >> I'll volunteer to do that cleanup. > > I think that would make the eventual merge of all the "nixes" > more difficult... > > Dan > > >> /Staffan >> >> On 15 feb 2012, at 21:24, Daniel D. Daugherty wrote: >> >>> The src/os/bsd code was derived from the src/os/linux code. >>> #ifdef _ALLBSD_SOURCE was used to flag (most) changes relative >>> to Linux for the BSD port. The #ifdef'ing is not perfect because >>> the Linux code also evolved as the BSD port was being done and >>> also because sometimes folks forgot to #ifdef their changes... >>> >>> Eventually, there is supposed to be a rework/rewrite in this area >>> where all the "nixes" share code. It won't be under src/os/posix, >>> but we'll think of some good name if the project ever gets done... >>> >>> Dan >>> >>> >>> On 2/15/12 12:30 PM, Staffan Larsen wrote: >>>> Reading this again, I wonder: What is the purpose of _ALLBSD_SOURCE in a file under 'src/os/bsd'? Are there platforms that are 'bad', but do not define _ALLBSD_SOURCE? >>>> >>>> /Staffan >>>> >>>> >>>> On 15 feb 2012, at 16:16, Daniel D. Daugherty wrote: >>>> >>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>>> It is used to identify code specific to the BSD family of OSes. >>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>>> identify code specific to MacOS X. >>>>> >>>>> Typically you'll see something like: >>>>> >>>>> #ifdef _ALLBSD_SOURCE >>>>> >>>>> >>>>> >>>>> #ifdef __APPLE__ >>>>> >>>>> #else >>>>> >>>>> #endif // __APPLE__ >>>>> #endif // _ALLBSD_SOURCE >>>>> >>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>> don't have the infrastructure to do it. >>>>> >>>>> Dan >>>>> >>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>>> >>>>>> /Mikael >>>>>> >>>>>> >>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>> Please review the following change: >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>> >>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>>> the pthread_t. >>>>>>> >>>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan From poonam.bajaj at oracle.com Thu Feb 16 04:01:53 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 16 Feb 2012 17:31:53 +0530 Subject: Request for review: 7145358: SA throws ClassCastException for partially loaded ConstantPool Message-ID: <4F3CF031.2020409@oracle.com> Request for review: CR 7145358 : SA throws ClassCastException for partially loaded ConstantPool webrev: http://cr.openjdk.java.net/~poonam/7145358/webrev.00/ Contributed by: Krystal Mok > If the poolHolder field in ConstantPool is not set, then printValueOn() in ConstantPool.java throws java.lang.ClassCastException. The fix is to first check if the poolHolder in ConstantPool is a valid Klass and only then print it. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120216/6fd98ce0/attachment.html From staffan.larsen at oracle.com Thu Feb 16 06:09:24 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 16 Feb 2012 15:09:24 +0100 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <4F3C0A17.9060403@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> <4F3C0188.1070909@oracle.com> <4F3C0A17.9060403@oracle.com> Message-ID: <82EC270C-35F5-44F3-8C93-0FD2BC0CB1EB@oracle.com> New webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.01/ I've tried not to break the bsd code. The code is less than readable with all the #ifdefs in there, but hopefully we can clean that up eventually. I'm a little unsure about the changes in vmStructs_bsd_x86.hpp - please look carefully. Thanks, /Staffan On 15 feb 2012, at 20:40, Paul Hohensee wrote: > Thanks! > > Paul > > On 2/15/12 2:25 PM, Staffan Larsen wrote: >> On 15 feb 2012, at 20:03, Paul Hohensee wrote: >> >>> On 2/15/12 1:58 PM, Staffan Larsen wrote: >>>> On 15 feb 2012, at 19:49, Paul Hohensee wrote: >>>> >>>>> Also, >>>>> >>>>> You can move the #include of mach.h into globalDefinitions_gcc.hpp, >>>>> in the #ifdef __APPLE__ section. That way, it won't cause a compile- >>>>> time error on non-osx platforms that don't have it. >>>> I dislike adding more stuff to globalDefinitions since that gets pulled in all over the place. I'd prefer to have #includes only where they are needed. >>> globalDefinitions_gcc.hpp is where these sorts of #includes currently live, >>> so I'd go with present practice rather than doing something new. If >>> you want to put the include of mach.h in os_bsd.inline.hpp, then you >>> should do something similar with all the platform-dependent includes >>> in globalDefinitions_gcc.hpp. >> I'd actually like to have it in osThread_bsd.hpp, but that isn't possible. I'll put in gloabalDefinitions_gcc.hpp. >> >> >>>>> The declaration of _thread_id, thread_id() and set_thread_id() in os_bsd.hpp >>>>> can be put under a #ifdef __APPLE__, vis., >>>>> >>>>> #ifdef _ALLBSD_SOURCE >>>>> #ifdef __APPLE__ >>>>> thread_t _thread_id; >>>>> #else >>>>> pthread_t _thread_id; >>>>> #endif >>>>> #endif >>>>> >>>>> The uses of mach_thread_self() in os_bsd.cpp can be similarly conditioned. >>>>> >>>>> If there's a thread_t defined by non-osx bsd implementations, then >>>>> you don't need predication in os_bsd.hpp, though you'd still need it >>>>> in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx >>>>> bsd platforms. >>>> I could do that, but the question is how much work we should put into not trying to break something that we can't test anyway. There's no way, even if I do this that I can verify that it works. >>> Even so, if we ever need to make hotspot work on non-osx bsd platforms, we'll >>> at least have markers to guide the work. >> OK - I'll try to fix things up. >> >> /Staffan >> >>> Paul >>> >>>> /Staffan >>>> >>>>> Thanks, >>>>> >>>>> Paul >>>>> >>>>> On 2/15/12 1:33 PM, Paul Hohensee wrote: >>>>>> Imo we should at least try to make non-osx bsd builds work, since >>>>>> the original code did work for non-osx builds. This change doesn't >>>>>> do that. >>>>>> >>>>>> In globalDefinitions_gcc.hpp, if you keep the lines >>>>>> >>>>>> #undef ELF_AC >>>>>> #undef EFL_ID >>>>>> >>>>>> then you don't have to change vm_version_x86.hpp. >>>>>> >>>>>> Paul >>>>>> >>>>>> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>>>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile infrastructure. >>>>>>> It is used to identify code specific to the BSD family of OSes. >>>>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it is used to >>>>>>> identify code specific to MacOS X. >>>>>>> >>>>>>> Typically you'll see something like: >>>>>>> >>>>>>> #ifdef _ALLBSD_SOURCE >>>>>>> >>>>>>> >>>>>>> >>>>>>> #ifdef __APPLE__ >>>>>>> >>>>>>> #else >>>>>>> >>>>>>> #endif // __APPLE__ >>>>>>> #endif // _ALLBSD_SOURCE >>>>>>> >>>>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>>>> don't have the infrastructure to do it. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>>>> Hi Staffan, >>>>>>>> >>>>>>>> It looks like you're adding Mac-specific stuff like thread_t and calls to ::mach_thread_self() inside _ALLBSD_SOURCE #ifdefs, are you sure this won't break BSD builds? >>>>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for (free|net|open)bsd? >>>>>>>> It's too bad we don't do regular builds on any of the BSDs, otherwise this would have been easier to figure out. >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>> >>>>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>>>> Please review the following change: >>>>>>>>> >>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>>>> >>>>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>>>> os::current_thread_id() on macosx to return the mach thread_t instead of >>>>>>>>> pthread_t. There is a separate method OSThread:pthread_id() that returns >>>>>>>>> the pthread_t. >>>>>>>>> >>>>>>>>> The reason for this change is both that JFR would like a 4 byte value >>>>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120216/a079c041/attachment-0001.html From daniel.daugherty at oracle.com Thu Feb 16 08:57:52 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Feb 2012 09:57:52 -0700 Subject: Request for review (M): 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX In-Reply-To: <82EC270C-35F5-44F3-8C93-0FD2BC0CB1EB@oracle.com> References: <4F3BB9B1.5020505@oracle.com> <4F3BCC52.8020703@oracle.com> <4F3BFA93.5000003@oracle.com> <4F3BFE23.5010602@oracle.com> <42725BF5-09CB-4B7F-B11D-F6F361E669E1@oracle.com> <4F3C0188.1070909@oracle.com> <4F3C0A17.9060403@oracle.com> <82EC270C-35F5-44F3-8C93-0FD2BC0CB1EB@oracle.com> Message-ID: <4F3D3590.4020906@oracle.com> On 2/16/12 7:09 AM, Staffan Larsen wrote: > New webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.01/ > Thumbs up! src/cpu/x86/vm/vm_version_x86.cpp No comments. src/os/bsd/vm/osThread_bsd.cpp No comments. src/os/bsd/vm/osThread_bsd.hpp No comments. src/os/bsd/vm/os_bsd.cpp line 5151 - it might be more clear to rename the local 'mach_thread' to something else. Yes, the underlying type is a "mach thread", but at this point, you've already abstracted to a thread_t. No other comments. src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp No comments. src/share/vm/utilities/globalDefinitions_gcc.hpp Please update copyright year to 2012. No other comments. > > I've tried not to break the bsd code. The code is less than readable > with all the #ifdefs in there, but hopefully we can clean that up > eventually. I'm a little unsure about the changes > in vmStructs_bsd_x86.hpp - please look carefully. > > Thanks, > /Staffan > > > On 15 feb 2012, at 20:40, Paul Hohensee wrote: > >> Thanks! >> >> Paul >> >> On 2/15/12 2:25 PM, Staffan Larsen wrote: >>> On 15 feb 2012, at 20:03, Paul Hohensee wrote: >>> >>>> On 2/15/12 1:58 PM, Staffan Larsen wrote: >>>>> On 15 feb 2012, at 19:49, Paul Hohensee wrote: >>>>> >>>>>> Also, >>>>>> >>>>>> You can move the #include of mach.h into globalDefinitions_gcc.hpp, >>>>>> in the #ifdef __APPLE__ section. That way, it won't cause a compile- >>>>>> time error on non-osx platforms that don't have it. >>>>> I dislike adding more stuff to globalDefinitions since that gets >>>>> pulled in all over the place. I'd prefer to have #includes only >>>>> where they are needed. >>>> globalDefinitions_gcc.hpp is where these sorts of #includes >>>> currently live, >>>> so I'd go with present practice rather than doing something new. If >>>> you want to put the include of mach.h in os_bsd.inline.hpp, then you >>>> should do something similar with all the platform-dependent includes >>>> in globalDefinitions_gcc.hpp. >>> I'd actually like to have it in osThread_bsd.hpp, but that isn't >>> possible. I'll put in gloabalDefinitions_gcc.hpp. >>> >>> >>>>>> The declaration of _thread_id, thread_id() and set_thread_id() in >>>>>> os_bsd.hpp >>>>>> can be put under a #ifdef __APPLE__, vis., >>>>>> >>>>>> #ifdef _ALLBSD_SOURCE >>>>>> #ifdef __APPLE__ >>>>>> thread_t _thread_id; >>>>>> #else >>>>>> pthread_t _thread_id; >>>>>> #endif >>>>>> #endif >>>>>> >>>>>> The uses of mach_thread_self() in os_bsd.cpp can be similarly >>>>>> conditioned. >>>>>> >>>>>> If there's a thread_t defined by non-osx bsd implementations, then >>>>>> you don't need predication in os_bsd.hpp, though you'd still need it >>>>>> in os_bsd.cpp. I'm assuming there's no mach_thread_self() on non-osx >>>>>> bsd platforms. >>>>> I could do that, but the question is how much work we should put >>>>> into not trying to break something that we can't test anyway. >>>>> There's no way, even if I do this that I can verify that it works. >>>> Even so, if we ever need to make hotspot work on non-osx bsd >>>> platforms, we'll >>>> at least have markers to guide the work. >>> OK - I'll try to fix things up. >>> >>> /Staffan >>> >>>> Paul >>>> >>>>> /Staffan >>>>> >>>>>> Thanks, >>>>>> >>>>>> Paul >>>>>> >>>>>> On 2/15/12 1:33 PM, Paul Hohensee wrote: >>>>>>> Imo we should at least try to make non-osx bsd builds work, since >>>>>>> the original code did work for non-osx builds. This change doesn't >>>>>>> do that. >>>>>>> >>>>>>> In globalDefinitions_gcc.hpp, if you keep the lines >>>>>>> >>>>>>> #undef ELF_AC >>>>>>> #undef EFL_ID >>>>>>> >>>>>>> then you don't have to change vm_version_x86.hpp. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On 2/15/12 10:16 AM, Daniel D. Daugherty wrote: >>>>>>>> The _ALLBSD_SOURCE symbol is defined by the HotSpot Makefile >>>>>>>> infrastructure. >>>>>>>> It is used to identify code specific to the BSD family of OSes. >>>>>>>> The __APPLE__ symbol is defined by the Apple compiler(s) and it >>>>>>>> is used to >>>>>>>> identify code specific to MacOS X. >>>>>>>> >>>>>>>> Typically you'll see something like: >>>>>>>> >>>>>>>> #ifdef _ALLBSD_SOURCE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> #ifdef __APPLE__ >>>>>>>> >>>>>>>> #else >>>>>>>> >>>>>>>> #endif // __APPLE__ >>>>>>>> #endif // _ALLBSD_SOURCE >>>>>>>> >>>>>>>> As for building on non-MacOS X BSDs, that would be nice, but we >>>>>>>> don't have the infrastructure to do it. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> On 2/15/12 6:57 AM, Mikael Gerdin wrote: >>>>>>>>> Hi Staffan, >>>>>>>>> >>>>>>>>> It looks like you're adding Mac-specific stuff like thread_t >>>>>>>>> and calls to ::mach_thread_self() inside _ALLBSD_SOURCE >>>>>>>>> #ifdefs, are you sure this won't break BSD builds? >>>>>>>>> Does the OSX compiler define _ALLBSD_SOURCE or is that for >>>>>>>>> (free|net|open)bsd? >>>>>>>>> It's too bad we don't do regular builds on any of the BSDs, >>>>>>>>> otherwise this would have been easier to figure out. >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2012-02-15 11:29, Staffan Larsen wrote: >>>>>>>>>> Please review the following change: >>>>>>>>>> >>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132070 >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~sla/7132070/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This changes the value returned by OSThread::thread_id() and >>>>>>>>>> os::current_thread_id() on macosx to return the mach thread_t >>>>>>>>>> instead of >>>>>>>>>> pthread_t. There is a separate method OSThread:pthread_id() >>>>>>>>>> that returns >>>>>>>>>> the pthread_t. >>>>>>>>>> >>>>>>>>>> The reason for this change is both that JFR would like a 4 >>>>>>>>>> byte value >>>>>>>>>> for thread id, and that SA requires access to the thread_t. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan > From xueming.shen at oracle.com Thu Feb 16 11:38:48 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 16 Feb 2012 19:38:48 +0000 Subject: hg: jdk8/tl/jdk: 6708398: Support integer overflow Message-ID: <20120216193906.57FC347522@hg.openjdk.java.net> Changeset: b971b51bec01 Author: sherman Date: 2012-02-16 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b971b51bec01 6708398: Support integer overflow Summary: Added add/sub/multiply/toIntExact methods to j.l.Math and StrictMath classes Reviewed-by: emcmanus Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/ExactArithTests.java + test/java/lang/StrictMath/ExactArithTests.java From paul.hohensee at oracle.com Thu Feb 16 14:15:43 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Thu, 16 Feb 2012 22:15:43 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7142113: Add Ivy Bridge to the known Intel x86 cpu families Message-ID: <20120216221547.B93054752C@hg.openjdk.java.net> Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp From coleen.phillimore at oracle.com Thu Feb 16 16:55:04 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Feb 2012 00:55:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120217005510.86C514752F@hg.openjdk.java.net> Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/df4927a3b82e Merge From john.coomes at oracle.com Thu Feb 16 21:01:29 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:01:29 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b26 for changeset 2accafff224a Message-ID: <20120217050129.E500847554@hg.openjdk.java.net> Changeset: 1533dfab9903 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/1533dfab9903 Added tag jdk8-b26 for changeset 2accafff224a ! .hgtags From john.coomes at oracle.com Thu Feb 16 21:01:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:01:36 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b26 for changeset 79f709a099f4 Message-ID: <20120217050138.AF83F47555@hg.openjdk.java.net> Changeset: 4fffe75e4edd Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/4fffe75e4edd Added tag jdk8-b26 for changeset 79f709a099f4 ! .hgtags From john.coomes at oracle.com Thu Feb 16 21:01:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:01:45 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b26 for changeset dbb7283c197b Message-ID: <20120217050145.C89E947556@hg.openjdk.java.net> Changeset: 80c47eb83d24 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/80c47eb83d24 Added tag jdk8-b26 for changeset dbb7283c197b ! .hgtags From john.coomes at oracle.com Thu Feb 16 21:01:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:01:53 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b26 for changeset 3518639eab6c Message-ID: <20120217050153.4B65A47557@hg.openjdk.java.net> Changeset: 329ace7198ac Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/329ace7198ac Added tag jdk8-b26 for changeset 3518639eab6c ! .hgtags From john.coomes at oracle.com Thu Feb 16 21:02:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:02:02 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b26 for changeset 5aca406e87cb Message-ID: <20120217050232.0F82047558@hg.openjdk.java.net> Changeset: 4196fc971f65 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4196fc971f65 Added tag jdk8-b26 for changeset 5aca406e87cb ! .hgtags From john.coomes at oracle.com Thu Feb 16 21:03:51 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 05:03:51 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b26 for changeset b556aa8a99c3 Message-ID: <20120217050358.5E11C47559@hg.openjdk.java.net> Changeset: fba3cbee0fa3 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fba3cbee0fa3 Added tag jdk8-b26 for changeset b556aa8a99c3 ! .hgtags From xueming.shen at oracle.com Thu Feb 16 22:08:11 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 17 Feb 2012 06:08:11 +0000 Subject: hg: jdk8/tl/jdk: 4153167: separate between ANSI and OEM code pages on Windows Message-ID: <20120217060835.1958E4755D@hg.openjdk.java.net> Changeset: d38fed7d2ea7 Author: sherman Date: 2012-02-16 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d38fed7d2ea7 4153167: separate between ANSI and OEM code pages on Windows Summary: To use OEM code page for System.out&err when not redirected Reviewed-by: alanb ! src/share/classes/java/lang/System.java ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/windows/native/java/lang/java_props_md.c From staffan.larsen at oracle.com Fri Feb 17 01:40:51 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Feb 2012 10:40:51 +0100 Subject: Request for review: 7145358: SA throws ClassCastException for partially loaded ConstantPool In-Reply-To: <4F3CF031.2020409@oracle.com> References: <4F3CF031.2020409@oracle.com> Message-ID: <0EEC7897-7286-455C-AFEB-C3401EB42B7A@oracle.com> Looks good! On 16 feb 2012, at 13:01, Poonam Bajaj wrote: > Request for review: > > CR 7145358: SA throws ClassCastException for partially loaded ConstantPool > webrev: http://cr.openjdk.java.net/~poonam/7145358/webrev.00/ > Contributed by: Krystal Mok > > If the poolHolder field in ConstantPool is not set, then printValueOn() > in ConstantPool.java throws java.lang.ClassCastException. The fix is to > first check if the poolHolder in ConstantPool is a valid Klass and only > then print it. > > > Thanks, > Poonam > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120217/588262f0/attachment.html From serguei.spitsyn at oracle.com Fri Feb 17 15:26:21 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Feb 2012 15:26:21 -0800 Subject: Request for review: 7145358: SA throws ClassCastException for partially loaded ConstantPool In-Reply-To: <4F3CF031.2020409@oracle.com> References: <4F3CF031.2020409@oracle.com> Message-ID: <4F3EE21D.7010202@oracle.com> Poonam, Looks good. Thanks, Serguei On 2/16/12 4:01 AM, Poonam Bajaj wrote: > Request for review: > > CR 7145358 > : SA > throws ClassCastException for partially loaded ConstantPool > webrev: http://cr.openjdk.java.net/~poonam/7145358/webrev.00/ > Contributed by: Krystal Mok > > > If the poolHolder field in ConstantPool is not set, then printValueOn() > in ConstantPool.java throws java.lang.ClassCastException. The fix is to > first check if the poolHolder in ConstantPool is a valid Klass and only > then print it. > > > Thanks, > Poonam > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120217/b10fa3c8/attachment.html From daniel.daugherty at oracle.com Fri Feb 17 17:53:28 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 18 Feb 2012 01:53:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7145798: System.loadLibrary does not search current working directory Message-ID: <20120218015331.7EC4947574@hg.openjdk.java.net> Changeset: 86ce3208eb18 Author: dcubed Date: 2012-02-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/86ce3208eb18 7145798: System.loadLibrary does not search current working directory Summary: Append "." to java.library.path on MacOS X to ease migration from Apple's Java6 to OpenJDK7. Reviewed-by: phh, jmelvin, coleenp ! src/os/bsd/vm/os_bsd.cpp From alan.bateman at oracle.com Sun Feb 19 08:56:53 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2012 16:56:53 +0000 Subject: hg: jdk8/tl/jdk: 7146152: File.path should be final Message-ID: <20120219165725.8D0CE4758B@hg.openjdk.java.net> Changeset: 24c298ef20a8 Author: forax Date: 2012-02-19 16:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24c298ef20a8 7146152: File.path should be final Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/io/File.java From staffan.larsen at oracle.com Mon Feb 20 02:03:42 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 20 Feb 2012 10:03:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX Message-ID: <20120220100346.8A35847597@hg.openjdk.java.net> Changeset: 0368109684cb Author: sla Date: 2012-02-19 13:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0368109684cb 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX Summary: Change OSThread to use mach thread_t Reviewed-by: phh, dcubed ! src/cpu/x86/vm/vm_version_x86.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp From littlee at linux.vnet.ibm.com Sun Feb 19 19:25:10 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Mon, 20 Feb 2012 03:25:10 +0000 Subject: hg: jdk8/tl/jdk: 7146506: (fc) Add EACCES check to the return of fcntl native method Message-ID: <20120220032520.DF77C47592@hg.openjdk.java.net> Changeset: de7f6d5841b6 Author: littlee Date: 2012-02-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de7f6d5841b6 7146506: (fc) Add EACCES check to the return of fcntl native method Summary: Add EACCES check according to the spec of fcntl Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c From alan.bateman at oracle.com Mon Feb 20 11:17:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 20 Feb 2012 19:17:49 +0000 Subject: hg: jdk8/tl/jdk: 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win] Message-ID: <20120220191811.BFD3E4759A@hg.openjdk.java.net> Changeset: 7326971f09af Author: alanb Date: 2012-02-20 18:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7326971f09af 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win] Reviewed-by: chegar, coffeys ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/native/sun/nio/ch/SocketDispatcher.c From alan.bateman at oracle.com Mon Feb 20 11:46:44 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 20 Feb 2012 19:46:44 +0000 Subject: hg: jdk8/tl/jdk: 7147087: Remove AWT/Swing/client tests from ProblemList Message-ID: <20120220194653.9333B4759B@hg.openjdk.java.net> Changeset: 5e56d498e913 Author: alanb Date: 2012-02-20 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e56d498e913 7147087: Remove AWT/Swing/client tests from ProblemList Reviewed-by: ohair ! test/Makefile ! test/ProblemList.txt From weijun.wang at oracle.com Mon Feb 20 16:51:46 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 21 Feb 2012 00:51:46 +0000 Subject: hg: jdk8/tl/jdk: 7144530: KeyTab.getInstance(String) no longer handles keyTabNames with "file:" prefix Message-ID: <20120221005205.244BC475A7@hg.openjdk.java.net> Changeset: 0243e7c0b0fb Author: weijun Date: 2012-02-21 08:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0243e7c0b0fb 7144530: KeyTab.getInstance(String) no longer handles keyTabNames with "file:" prefix Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/ktab/FileKeyTab.java From weijun.wang at oracle.com Mon Feb 20 23:12:04 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 21 Feb 2012 07:12:04 +0000 Subject: hg: jdk8/tl/jdk: 7147336: clarification on warning of keytool -printcrl Message-ID: <20120221071214.6B8A9475AC@hg.openjdk.java.net> Changeset: b739dd7ce59c Author: weijun Date: 2012-02-21 15:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b739dd7ce59c 7147336: clarification on warning of keytool -printcrl Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java From poonam.bajaj at sun.com Mon Feb 20 23:26:12 2012 From: poonam.bajaj at sun.com (poonam.bajaj at sun.com) Date: Tue, 21 Feb 2012 07:26:12 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7145358: SA throws ClassCastException for partially loaded ConstantPool Message-ID: <20120221072614.65851475AD@hg.openjdk.java.net> Changeset: 38fd165da001 Author: poonam Date: 2012-02-20 21:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/38fd165da001 7145358: SA throws ClassCastException for partially loaded ConstantPool Summary: In printValueOn() in ConstantPool.java check if the poolHolder is a valid Klass and only then print it. Reviewed-by: sla, sspitsyn Contributed-by: Krystal Mok ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java From xuelei.fan at oracle.com Tue Feb 21 05:45:19 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 21 Feb 2012 13:45:19 +0000 Subject: hg: jdk8/tl/jdk: 7147407: remove never used debug code in DnsClient.java Message-ID: <20120221134528.F0E75475B5@hg.openjdk.java.net> Changeset: a4e3dde9a8a7 Author: xuelei Date: 2012-02-21 05:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4e3dde9a8a7 7147407: remove never used debug code in DnsClient.java Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/dns/DnsClient.java From staffan.larsen at oracle.com Wed Feb 22 00:26:37 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Feb 2012 09:26:37 +0100 Subject: SA frontends Message-ID: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> I'm trying to figure out what the different front ends to SA are and how they differ. So far I have identified the following: HSDB - basic UI CLHSDB - command line version of HSDB BugSpot - improvement over HSDB ?? JSDB - JavaScript command line SOQL - Simple Object Query Language command line Have I missed any? What are your experiences with these? Which ones are most used? Should we maintain all of them? Can we consolidate them into one? Specifically: what is the difference between HSDB and BugSpot? I'd be happy for all and any feedback, /Staffan From mikael.gerdin at oracle.com Wed Feb 22 01:09:30 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 22 Feb 2012 10:09:30 +0100 Subject: SA frontends In-Reply-To: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> Message-ID: <4F44B0CA.6080604@oracle.com> Hi Staffan On 2012-02-22 09:26, Staffan Larsen wrote: > I'm trying to figure out what the different front ends to SA are and how they differ. So far I have identified the following: > > HSDB - basic UI > CLHSDB - command line version of HSDB > BugSpot - improvement over HSDB ?? > JSDB - JavaScript command line > SOQL - Simple Object Query Language command line > > Have I missed any? I think that several of the command-line "servicability" tools use the SA code when working on core files. Looking in the agent/src/share/classes/sun/jvm/hotspot/tools/ there are classes for jmap, jinfo and jstack. /Mikael > > What are your experiences with these? Which ones are most used? Should we maintain all of them? Can we consolidate them into one? Specifically: what is the difference between HSDB and BugSpot? > > I'd be happy for all and any feedback, > /Staffan From rednaxelafx at gmail.com Wed Feb 22 01:34:05 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 22 Feb 2012 17:34:05 +0800 Subject: SA frontends In-Reply-To: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> Message-ID: Hi Staffan, There's at least another frontend, the SA Plugin for Visual VM. I think it only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't use stuff from BugSpot. Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly SA frontends, but use the SA to implement their functionality. I use CLHSDB a lot when I poke around the internals of HotSpot. It's good for its purpose, except that history support is really weird, e.g. pressing up arrow give "^[[A". When I need commands not available in CLHSDB yet, I can write a JavaScript file and use "jsload" in CLHSDB to extend it with new commands. Example here: [1]. I seldom use JSDB directly, because the command style of CLHSDB works better, if the commands cover all the needs during a debugging session. When writing new commands for CLHSDB, sometimes I use the "jseval" command to try things out first, before actually writing them into a script file. That overlaps with what JSDB does, but of course prototyping in JSDB would be much nicer than in CLHSDB. On the top of my wishlist on CLHSDB, I'd wish for: 1. better input support (something like jline would be great) 2. AMD64 disassembler support (not frontend issue) 3. live stepping/breakpointing support (not frontend issue) If 2 and 3 is implemented, I might be able to spend more time in CLHSDB, where sometimes I have to use a native debugger like gdb. But these aren't frontend issue anyway. I'd be grateful for any advise on how to debug a product build HotSpot with gdb instead of CLHSDB, where a lot of debugging support functions are not available in HotSpot itself and the symbols are inconvenient to access. On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne 2011. The "Future Plans" part sounds interesting. I think this plugin is the most visible way to use SA for most end users. It'd be great if it could be open sourced and made more extensible, say, embedding a variant of CLHSDB into this plugin. Regards, Kris Mok [1]: https://gist.github.com/1393698 On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen wrote: > I'm trying to figure out what the different front ends to SA are and how > they differ. So far I have identified the following: > > HSDB - basic UI > CLHSDB - command line version of HSDB > BugSpot - improvement over HSDB ?? > JSDB - JavaScript command line > SOQL - Simple Object Query Language command line > > Have I missed any? > > What are your experiences with these? Which ones are most used? Should we > maintain all of them? Can we consolidate them into one? Specifically: what > is the difference between HSDB and BugSpot? > > I'd be happy for all and any feedback, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120222/a2811d50/attachment.html From staffan.larsen at oracle.com Wed Feb 22 01:34:24 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Feb 2012 10:34:24 +0100 Subject: SA frontends In-Reply-To: <4F44B0CA.6080604@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> <4F44B0CA.6080604@oracle.com> Message-ID: <287300D2-2FA2-4696-A90C-792D425FC0A5@oracle.com> On 22 feb 2012, at 10:09, Mikael Gerdin wrote: > On 2012-02-22 09:26, Staffan Larsen wrote: >> I'm trying to figure out what the different front ends to SA are and how they differ. So far I have identified the following: >> >> HSDB - basic UI >> CLHSDB - command line version of HSDB >> BugSpot - improvement over HSDB ?? >> JSDB - JavaScript command line >> SOQL - Simple Object Query Language command line >> >> Have I missed any? > > I think that several of the command-line "servicability" tools use the SA code when working on core files. > Looking in the agent/src/share/classes/sun/jvm/hotspot/tools/ > there are classes for jmap, jinfo and stack. Right. I didn't think of those as "front ends", but of course they are (if limited). /Staffan From sundararajan.athijegannathan at oracle.com Wed Feb 22 02:22:16 2012 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 22 Feb 2012 15:52:16 +0530 Subject: SA frontends In-Reply-To: References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> Message-ID: <4F44C1D8.6000109@oracle.com> Hi, SA uses stop-the-world to debug "snapshot" of the process. BugSpot was supposed to be a SA model where you can pause/resume and keep looking at different snapshots (as well as use JDI to look at process state). But, it was never implemented that way. Over the years lot of stuff accumulated assuming the snapshot model as well. And yes, JSDB may not be directly useful - but you can use most of functionality CLHSDB using script "load" as Kris mentioned. SOQL: Better option is to retrieve heap dump from core/process using jmap (or SA internals) and view it by jhat or VisualVM. -Sundar Krystal Mok wrote: > Hi Staffan, > > There's at least another frontend, the SA Plugin for Visual VM. I > think it only uses the BugSpotAgent for attaching/detaching, otherwise > it doesn't use stuff from BugSpot. > Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly > SA frontends, but use the SA to implement their functionality. > > I use CLHSDB a lot when I poke around the internals of HotSpot. It's > good for its purpose, except that history support is really weird, > e.g. pressing up arrow give "^[[A". When I need commands not available > in CLHSDB yet, I can write a JavaScript file and use "jsload" in > CLHSDB to extend it with new commands. Example here: [1]. > > I seldom use JSDB directly, because the command style of CLHSDB works > better, if the commands cover all the needs during a debugging > session. When writing new commands for CLHSDB, sometimes I use the > "jseval" command to try things out first, before actually writing them > into a script file. That overlaps with what JSDB does, but of course > prototyping in JSDB would be much nicer than in CLHSDB. > > On the top of my wishlist on CLHSDB, I'd wish for: > 1. better input support (something like jline would be great) > 2. AMD64 disassembler support (not frontend issue) > 3. live stepping/breakpointing support (not frontend issue) > > If 2 and 3 is implemented, I might be able to spend more time in > CLHSDB, where sometimes I have to use a native debugger like gdb. But > these aren't frontend issue anyway. I'd be grateful for any advise on > how to debug a product build HotSpot with gdb instead of CLHSDB, where > a lot of debugging support functions are not available in HotSpot > itself and the symbols are inconvenient to access. > > On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne > 2011. The "Future Plans" part sounds interesting. I think this plugin > is the most visible way to use SA for most end users. It'd be great if > it could be open sourced and made more extensible, say, embedding a > variant of CLHSDB into this plugin. > > Regards, > Kris Mok > > [1]: https://gist.github.com/1393698 > > On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen > > wrote: > > I'm trying to figure out what the different front ends to SA are > and how they differ. So far I have identified the following: > > HSDB - basic UI > CLHSDB - command line version of HSDB > BugSpot - improvement over HSDB ?? > JSDB - JavaScript command line > SOQL - Simple Object Query Language command line > > Have I missed any? > > What are your experiences with these? Which ones are most used? > Should we maintain all of them? Can we consolidate them into one? > Specifically: what is the difference between HSDB and BugSpot? > > I'd be happy for all and any feedback, > /Staffan > > From frederic.parain at oracle.com Wed Feb 22 10:27:29 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 22 Feb 2012 18:27:29 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 31 new changesets Message-ID: <20120222182829.9B4134762C@hg.openjdk.java.net> Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9961b6498f9 Merge Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/be398bba40e9 Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d3384450b649 Merge Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags Changeset: 4ab89de75552 Author: amurillo Date: 2012-02-17 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4ab89de75552 7146700: new hotspot build - hs24-b01 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1a4e5feb63c4 Author: fparain Date: 2012-02-22 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a4e5feb63c4 Merge From dmitriy.samersoff at oracle.com Wed Feb 22 12:35:32 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Wed, 22 Feb 2012 20:35:32 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120222203538.B29B447631@hg.openjdk.java.net> Changeset: 645162d94294 Author: dsamersoff Date: 2012-02-22 19:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/645162d94294 7110104: It should be possible to stop and start JMX Agent at runtime Summary: Added a capability to start and stop JMX Agent by jcmd Reviewed-by: acorn, mchung ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: b5ab7482dbf9 Author: dsamersoff Date: 2012-02-22 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b5ab7482dbf9 Merge From lana.steuck at oracle.com Wed Feb 22 21:25:59 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:25:59 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b26 for changeset 2accafff224a Message-ID: <20120223052559.7CF2F47648@hg.openjdk.java.net> Changeset: 1533dfab9903 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1533dfab9903 Added tag jdk8-b26 for changeset 2accafff224a ! .hgtags From lana.steuck at oracle.com Wed Feb 22 21:25:59 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:25:59 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b26 for changeset 79f709a099f4 Message-ID: <20120223052601.C861347649@hg.openjdk.java.net> Changeset: 4fffe75e4edd Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4fffe75e4edd Added tag jdk8-b26 for changeset 79f709a099f4 ! .hgtags From lana.steuck at oracle.com Wed Feb 22 21:26:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:03 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b26 for changeset dbb7283c197b Message-ID: <20120223052603.12C034764A@hg.openjdk.java.net> Changeset: 80c47eb83d24 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/80c47eb83d24 Added tag jdk8-b26 for changeset dbb7283c197b ! .hgtags From lana.steuck at oracle.com Wed Feb 22 21:26:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:07 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120223052608.070D04764B@hg.openjdk.java.net> Changeset: 329ace7198ac Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/329ace7198ac Added tag jdk8-b26 for changeset 3518639eab6c ! .hgtags Changeset: 38c037af4127 Author: lana Date: 2012-02-18 16:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/38c037af4127 Merge From lana.steuck at oracle.com Wed Feb 22 21:26:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:12 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120223052620.EA04C4764C@hg.openjdk.java.net> Changeset: fba3cbee0fa3 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fba3cbee0fa3 Added tag jdk8-b26 for changeset b556aa8a99c3 ! .hgtags Changeset: e127334a64fe Author: darcy Date: 2012-02-17 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e127334a64fe 7143910: test/tools/apt/Basics/apt.sh fails with 'real' sh Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/apt/Basics/apt.sh Changeset: be456f9c64e8 Author: lana Date: 2012-02-18 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be456f9c64e8 Merge - make/test/lib/apt.sh - src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java - src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java - src/share/classes/com/sun/mirror/apt/Filer.java - src/share/classes/com/sun/mirror/apt/Messager.java - src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java - src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java - src/share/classes/com/sun/mirror/apt/RoundState.java - src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java - src/share/classes/com/sun/mirror/declaration/AnnotationValue.java - src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java - src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java - src/share/classes/com/sun/mirror/declaration/Declaration.java - src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java - src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java - src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java - src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java - src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java - src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java - src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java - src/share/classes/com/sun/mirror/declaration/Modifier.java - src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java - src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java - src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java - src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/overview.html - src/share/classes/com/sun/mirror/type/AnnotationType.java - src/share/classes/com/sun/mirror/type/ArrayType.java - src/share/classes/com/sun/mirror/type/ClassType.java - src/share/classes/com/sun/mirror/type/DeclaredType.java - src/share/classes/com/sun/mirror/type/EnumType.java - src/share/classes/com/sun/mirror/type/InterfaceType.java - src/share/classes/com/sun/mirror/type/MirroredTypeException.java - src/share/classes/com/sun/mirror/type/MirroredTypesException.java - src/share/classes/com/sun/mirror/type/PrimitiveType.java - src/share/classes/com/sun/mirror/type/ReferenceType.java - src/share/classes/com/sun/mirror/type/TypeMirror.java - src/share/classes/com/sun/mirror/type/TypeVariable.java - src/share/classes/com/sun/mirror/type/VoidType.java - src/share/classes/com/sun/mirror/type/WildcardType.java - src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/util/DeclarationFilter.java - src/share/classes/com/sun/mirror/util/DeclarationScanner.java - src/share/classes/com/sun/mirror/util/DeclarationVisitor.java - src/share/classes/com/sun/mirror/util/DeclarationVisitors.java - src/share/classes/com/sun/mirror/util/Declarations.java - src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java - src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java - src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java - src/share/classes/com/sun/mirror/util/SourcePosition.java - src/share/classes/com/sun/mirror/util/TypeVisitor.java - src/share/classes/com/sun/mirror/util/Types.java - src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/tools/apt/Main.java - src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java - src/share/classes/com/sun/tools/apt/comp/Apt.java - src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java - src/share/classes/com/sun/tools/apt/comp/PrintAP.java - src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java - src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/CommandLine.java - src/share/classes/com/sun/tools/apt/main/Main.java - src/share/classes/com/sun/tools/apt/mirror/AptEnv.java - src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java - src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java - src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java - src/share/classes/com/sun/tools/apt/resources/apt.properties - src/share/classes/com/sun/tools/apt/resources/apt_ja.properties - src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties - src/share/classes/com/sun/tools/apt/util/Bark.java - test/tools/apt/Basics/Aggregate.java - test/tools/apt/Basics/ClassAnnotations.java - test/tools/apt/Basics/FreshnessApf.java - test/tools/apt/Basics/GenClass.java - test/tools/apt/Basics/Indirect.java - test/tools/apt/Basics/Lacuna.java - test/tools/apt/Basics/MethodAnnotations.java - test/tools/apt/Basics/Milk.java - test/tools/apt/Basics/MisMatch.java - test/tools/apt/Basics/Misc.java - test/tools/apt/Basics/MyMarker.java - test/tools/apt/Basics/MySimple.java - test/tools/apt/Basics/NestedClassAnnotations.java - test/tools/apt/Basics/ParameterAnnotations.java - test/tools/apt/Basics/StaticFieldAnnotations.java - test/tools/apt/Basics/StaticMethodAnnotations.java - test/tools/apt/Basics/TestGetPackageApf.java - test/tools/apt/Basics/TestGetTypeDeclarationApf.java - test/tools/apt/Basics/annot/AnnotMarker.java - test/tools/apt/Basics/annot/AnnotShangri_la.java - test/tools/apt/Basics/annot/AnnotSimple.java - test/tools/apt/Basics/annot/annot2/AnnotMarker2.java - test/tools/apt/Basics/annot/annot2/AnnotSimple2.java - test/tools/apt/Basics/com.sun.mirror.apt.AnnotationProcessorFactory - test/tools/apt/Basics/foo/bar/Baz.java - test/tools/apt/Basics/foo/bar/Quux.java - test/tools/apt/Basics/golden.txt - test/tools/apt/Basics/goldenAggregate.txt - test/tools/apt/Basics/p1/p2.java - test/tools/apt/Basics/p1/p2/C1.java - test/tools/apt/Basics/print.sh - test/tools/apt/Compile/ClassDeclApf.java - test/tools/apt/Compile/ClassDeclApf2.java - test/tools/apt/Compile/Dummy1.java - test/tools/apt/Compile/ErrorAPF.java - test/tools/apt/Compile/HelloAnnotation.java - test/tools/apt/Compile/HelloWorld.java - test/tools/apt/Compile/Round1Apf.java - test/tools/apt/Compile/Round2Apf.java - test/tools/apt/Compile/Round3Apf.java - test/tools/apt/Compile/Round4Apf.java - test/tools/apt/Compile/Rounds.java - test/tools/apt/Compile/StaticApf.java - test/tools/apt/Compile/WarnAPF.java - test/tools/apt/Compile/WrappedStaticApf.java - test/tools/apt/Compile/compile.sh - test/tools/apt/Compile/golden.txt - test/tools/apt/Compile/goldenFactory.txt - test/tools/apt/Compile/goldenWarn.txt - test/tools/apt/Compile/servicesRound1 - test/tools/apt/Compile/servicesRound2 - test/tools/apt/Compile/servicesRound3 - test/tools/apt/Compile/servicesRound4 - test/tools/apt/Compile/servicesStaticApf - test/tools/apt/Compile/src/AhOneClass.java - test/tools/apt/Compile/src/AndAhTwoClass.java - test/tools/apt/Compile/src/Round1Class.java - test/tools/apt/Discovery/Dee.java - test/tools/apt/Discovery/Dum.java - test/tools/apt/Discovery/Empty.java - test/tools/apt/Discovery/PhantomTouch.java - test/tools/apt/Discovery/PhantomUpdate.java - test/tools/apt/Discovery/Touch.java - test/tools/apt/Discovery/discovery.sh - test/tools/apt/Discovery/servicesBadTouch - test/tools/apt/Discovery/servicesPhantomTouch - test/tools/apt/Discovery/servicesTouch - test/tools/apt/Discovery/servicesTweedle - test/tools/apt/Misc/Marked.java - test/tools/apt/Misc/Marker.java - test/tools/apt/Misc/Misc.java - test/tools/apt/Misc/misc.sh - test/tools/apt/Misc/servicesMisc - test/tools/apt/Options/Marked.java - test/tools/apt/Options/Marker.java - test/tools/apt/Options/OptionChecker.java - test/tools/apt/Options/options.sh - test/tools/apt/Options/servicesOptions - test/tools/apt/Scanners/Counter.java - test/tools/apt/Scanners/MemberOrderApf.java - test/tools/apt/Scanners/Order.java - test/tools/apt/Scanners/Scanner.java - test/tools/apt/Scanners/TestEnum.java - test/tools/apt/Scanners/VisitOrder.java - test/tools/apt/Scanners/scanner.sh - test/tools/apt/Scanners/servicesScanner - test/tools/apt/lib/Ignore.java - test/tools/apt/lib/Test.java - test/tools/apt/lib/TestProcessor.java - test/tools/apt/lib/TestProcessorFactory.java - test/tools/apt/lib/Tester.java - test/tools/apt/mirror/declaration/AnnoMirror.java - test/tools/apt/mirror/declaration/AnnoTypeDecl.java - test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java - test/tools/apt/mirror/declaration/AnnoVal.java - test/tools/apt/mirror/declaration/ClassDecl.java - test/tools/apt/mirror/declaration/ConstExpr.java - test/tools/apt/mirror/declaration/ConstructorDecl.java - test/tools/apt/mirror/declaration/EnumDecl.java - test/tools/apt/mirror/declaration/FieldDecl.java - test/tools/apt/mirror/declaration/GetAnno.java - test/tools/apt/mirror/declaration/InterfaceDecl.java - test/tools/apt/mirror/declaration/MethodDecl.java - test/tools/apt/mirror/declaration/PackageDecl.java - test/tools/apt/mirror/declaration/ParameterDecl.java - test/tools/apt/mirror/declaration/pkg1/AClass.java - test/tools/apt/mirror/declaration/pkg1/AnAnnoType.java - test/tools/apt/mirror/declaration/pkg1/AnEnum.java - test/tools/apt/mirror/declaration/pkg1/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/package-info.java - test/tools/apt/mirror/declaration/pkg1/pkg2/AnInterface.java - test/tools/apt/mirror/declaration/pkg1/pkg2/package.html - test/tools/apt/mirror/type/AnnoTyp.java - test/tools/apt/mirror/type/ArrayTyp.java - test/tools/apt/mirror/type/ClassTyp.java - test/tools/apt/mirror/type/EnumTyp.java - test/tools/apt/mirror/type/InterfaceTyp.java - test/tools/apt/mirror/type/PrimitiveTyp.java - test/tools/apt/mirror/type/TypeVar.java - test/tools/apt/mirror/type/WildcardTyp.java - test/tools/apt/mirror/util/Overrides.java - test/tools/apt/mirror/util/TypeCreation.java From lana.steuck at oracle.com Wed Feb 22 21:26:31 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:31 +0000 Subject: hg: jdk8/tl/hotspot: 69 new changesets Message-ID: <20120223052854.021A74764D@hg.openjdk.java.net> Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea677dbdd883 Merge Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f985b6ce7ff Merge Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9961b6498f9 Merge Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be398bba40e9 Merge Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea527c5cde03 Merge Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1bb2838e2fc1 Merge Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a9ac4910e7f2 Merge Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf772dff4bfd Merge Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91a81502a27d Merge Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64fc5ac1b770 Merge Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df4927a3b82e Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3384450b649 Merge Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags From lana.steuck at oracle.com Wed Feb 22 21:26:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Feb 2012 05:26:54 +0000 Subject: hg: jdk8/tl/jdk: 21 new changesets Message-ID: <20120223053034.269E347650@hg.openjdk.java.net> Changeset: 4196fc971f65 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4196fc971f65 Added tag jdk8-b26 for changeset 5aca406e87cb ! .hgtags Changeset: 7a5c8c6f1c6b Author: prr Date: 2012-02-03 09:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a5c8c6f1c6b 7141914: Draw glyph cause JVM crash Reviewed-by: bae, igor ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 996cd6e8d00e Author: lana Date: 2012-02-09 19:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/996cd6e8d00e Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: a06fd6ada85c Author: prr Date: 2012-02-14 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a06fd6ada85c 7143612: improve backwards compatibility of OSIS post-CR6887286 Reviewed-by: flar, prr Contributed-by: david.buck at oracle.com ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 45ce82d366ec Author: anthony Date: 2012-02-02 17:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45ce82d366ec 7132194: GtkFileDialog does not point to the correct file(s) is Recent Files are used. Summary: Handle the file list differently if gtk_file_chooser_get_current_folder() returns NULL Reviewed-by: anthony Contributed-by: Matthew Smith ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 10fa63972ad5 Author: rupashka Date: 2012-02-03 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10fa63972ad5 7141573: JProgressBar resize exception, if setStringPainted in Windows LAF Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java + test/javax/swing/JProgressBar/7141573/bug7141573.java Changeset: 34571be262e9 Author: rupashka Date: 2012-02-03 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34571be262e9 7071775: javax/swing/JFileChooser/6396844/TwentyThousandTest.java failed on winxp Reviewed-by: alexp ! test/javax/swing/JFileChooser/6396844/TwentyThousandTest.java Changeset: 1880e8cc89b8 Author: rupashka Date: 2012-02-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1880e8cc89b8 7138665: JOptionPane.getValue() unexpected change between JRE 1.6 and JRE 1.7 Reviewed-by: alexp ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java + test/javax/swing/JOptionPane/7138665/bug7138665.java Changeset: d2e067142112 Author: bagiras Date: 2012-02-08 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2e067142112 7132367: [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit Reviewed-by: art ! test/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java Changeset: d43447758eba Author: rupashka Date: 2012-02-09 14:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d43447758eba 7143857: Memory leak in javax.swing.plaf.synth.SynthTreeUI Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java Changeset: 403e3bb8a162 Author: rupashka Date: 2012-02-09 18:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/403e3bb8a162 7142955: DefaultTreeCellRenderer doesn't honor 'Tree.rendererFillBackground' LAF property Reviewed-by: malenkov ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java + test/javax/swing/tree/DefaultTreeCellRenderer/7142955/bug7142955.java Changeset: a3b50244bd10 Author: chegar Date: 2012-02-10 11:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3b50244bd10 7144475: fix some warnings in java.awt, javax.print.attribute.standard, and sun.beans.infos Reviewed-by: chegar, prr, alanb, anthony Contributed-by: Prasannaa , Martijn Verburg , Goerge Albrecht , Graham Allan , Iordanis Giannakakis , Jose Llarena , Abrahamn Marin Perez ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/sun/beans/infos/ComponentBeanInfo.java Changeset: 55adee49df8e Author: alexsch Date: 2012-02-10 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55adee49df8e 7109991: SwingUtilities.isXMouseButton behaves unexpectedly starting from JDK8 b08 Reviewed-by: rupashka ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java Changeset: de74d3310e96 Author: lana Date: 2012-02-09 23:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de74d3310e96 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 081a44952699 Author: lana Date: 2012-02-10 10:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/081a44952699 Merge Changeset: 3f4701d08418 Author: bagiras Date: 2012-02-13 17:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f4701d08418 7143070: test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java freezes on exit Reviewed-by: anthony ! test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java Changeset: a1dc74291966 Author: alexsch Date: 2012-02-14 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1dc74291966 7133577: [macosx] closed/javax/swing/JTree/4314199/bug4314199.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/4314199/bug4314199.html + test/javax/swing/JTree/4314199/bug4314199.java Changeset: 24e30ae2a192 Author: lana Date: 2012-02-15 15:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24e30ae2a192 Merge Changeset: 2a3f026b3a29 Author: lana Date: 2012-02-15 15:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3f026b3a29 Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java Changeset: c68342532e2e Author: lana Date: 2012-02-18 16:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c68342532e2e Merge - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java - src/share/classes/com/sun/management/DiagnosticCommandInfo.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java - src/solaris/classes/sun/nio/ch/SctpChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpNet.java - src/solaris/classes/sun/nio/ch/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java - test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java Changeset: 6a5d6b2800f6 Author: lana Date: 2012-02-22 16:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a5d6b2800f6 Merge From poonam.bajaj at oracle.com Wed Feb 22 22:18:01 2012 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 23 Feb 2012 11:48:01 +0530 Subject: SA frontends In-Reply-To: References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> Message-ID: <4F45DA19.4060207@oracle.com> Hi Kris, SA-Plugin for VisualVM uses HotspotAgent - SA interface provided by class sun.jvm.hotspot.HotSpotAgent. SA-Plugin uses the attach/detach functionality provided by this class and it uses other SA classes (e.g. sun.jvm.hotspot.runtime.*, sun.jvm.hotspot.ui.*) to extract and display data in VisualVM views. SA-Plugin code is available in the VisualVM source base under 'plugins' suite. Instructions to get the code: http://visualvm.java.net/build.html. VisualVM is a project on java.net and I think members of the project having contributor role should be able to contribute to the project. Thanks, Poonam On 2/22/2012 3:04 PM, Krystal Mok wrote: > Hi Staffan, > > There's at least another frontend, the SA Plugin for Visual VM. I > think it only uses the BugSpotAgent for attaching/detaching, otherwise > it doesn't use stuff from BugSpot. > Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly > SA frontends, but use the SA to implement their functionality. > > I use CLHSDB a lot when I poke around the internals of HotSpot. It's > good for its purpose, except that history support is really weird, > e.g. pressing up arrow give "^[[A". When I need commands not available > in CLHSDB yet, I can write a JavaScript file and use "jsload" in > CLHSDB to extend it with new commands. Example here: [1]. > > I seldom use JSDB directly, because the command style of CLHSDB works > better, if the commands cover all the needs during a debugging > session. When writing new commands for CLHSDB, sometimes I use the > "jseval" command to try things out first, before actually writing them > into a script file. That overlaps with what JSDB does, but of course > prototyping in JSDB would be much nicer than in CLHSDB. > > On the top of my wishlist on CLHSDB, I'd wish for: > 1. better input support (something like jline would be great) > 2. AMD64 disassembler support (not frontend issue) > 3. live stepping/breakpointing support (not frontend issue) > > If 2 and 3 is implemented, I might be able to spend more time in > CLHSDB, where sometimes I have to use a native debugger like gdb. But > these aren't frontend issue anyway. I'd be grateful for any advise on > how to debug a product build HotSpot with gdb instead of CLHSDB, where > a lot of debugging support functions are not available in HotSpot > itself and the symbols are inconvenient to access. > > On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne > 2011. The "Future Plans" part sounds interesting. I think this plugin > is the most visible way to use SA for most end users. It'd be great if > it could be open sourced and made more extensible, say, embedding a > variant of CLHSDB into this plugin. > > Regards, > Kris Mok > > [1]: https://gist.github.com/1393698 > > On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen > > wrote: > > I'm trying to figure out what the different front ends to SA are > and how they differ. So far I have identified the following: > > HSDB - basic UI > CLHSDB - command line version of HSDB > BugSpot - improvement over HSDB ?? > JSDB - JavaScript command line > SOQL - Simple Object Query Language command line > > Have I missed any? > > What are your experiences with these? Which ones are most used? > Should we maintain all of them? Can we consolidate them into one? > Specifically: what is the difference between HSDB and BugSpot? > > I'd be happy for all and any feedback, > /Staffan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120223/e12e5569/attachment.html From david.holmes at oracle.com Thu Feb 23 00:57:26 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 23 Feb 2012 08:57:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable Message-ID: <20120223085730.A5AAB47653@hg.openjdk.java.net> Changeset: 7292cff45988 Author: erikj Date: 2012-02-22 09:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7292cff45988 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable Reviewed-by: dholmes, ohrstrom, ohair, jcoomes ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sparcWorks.make ! make/defs.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sparcWorks.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/sparcWorks.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make From frederic.parain at oracle.com Thu Feb 23 07:36:39 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 23 Feb 2012 16:36:39 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale Message-ID: <4F465D07.5000302@oracle.com> This a simple fix to solve CR 6988220: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 The use of String.intern() in the ObjectName class prevents the class the scale well when more than 20K ObjectNames are managed. The fix simply removes the use of String.intern(), and uses regular String instead. The Object.equals() method is modified too to make a regular String comparison. The complexity of this method now depends on the length of the ObjectName's canonical name, and is not impacted any more by the number of ObjectName instances being handled. The Webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ I've tested this fix with the jdk_lang and jdk_management test suites. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From staffan.larsen at oracle.com Thu Feb 23 07:31:04 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Feb 2012 16:31:04 +0100 Subject: SA frontends In-Reply-To: <4F44C1D8.6000109@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> <4F44C1D8.6000109@oracle.com> Message-ID: <8D856712-CE77-4228-BD85-BC45FF8F379C@oracle.com> On 22 feb 2012, at 11:22, A. Sundararajan wrote: > SA uses stop-the-world to debug "snapshot" of the process. BugSpot was supposed to be a SA model where you can pause/resume and keep looking at different snapshots (as well as use JDI to look at process state). But, it was never implemented that way. Over the years lot of stuff accumulated assuming the snapshot model as well. So what does BugSpot have that HSDB does not (and the other way around)? Could one of them be retired? > And yes, JSDB may not be directly useful - but you can use most of functionality CLHSDB using script "load" as Kris mentioned. So maybe CLHSDB can be improved and JSDB retired? > SOQL: Better option is to retrieve heap dump from core/process using jmap (or SA internals) and view it by jhat or VisualVM. Same thing here? Thanks for the feedback, /Staffan > > -Sundar > > Krystal Mok wrote: >> Hi Staffan, >> >> There's at least another frontend, the SA Plugin for Visual VM. I think it only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't use stuff from BugSpot. >> Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly SA frontends, but use the SA to implement their functionality. >> >> I use CLHSDB a lot when I poke around the internals of HotSpot. It's good for its purpose, except that history support is really weird, e.g. pressing up arrow give "^[[A". When I need commands not available in CLHSDB yet, I can write a JavaScript file and use "jsload" in CLHSDB to extend it with new commands. Example here: [1]. >> >> I seldom use JSDB directly, because the command style of CLHSDB works better, if the commands cover all the needs during a debugging session. When writing new commands for CLHSDB, sometimes I use the "jseval" command to try things out first, before actually writing them into a script file. That overlaps with what JSDB does, but of course prototyping in JSDB would be much nicer than in CLHSDB. >> >> On the top of my wishlist on CLHSDB, I'd wish for: >> 1. better input support (something like jline would be great) >> 2. AMD64 disassembler support (not frontend issue) >> 3. live stepping/breakpointing support (not frontend issue) >> >> If 2 and 3 is implemented, I might be able to spend more time in CLHSDB, where sometimes I have to use a native debugger like gdb. But these aren't frontend issue anyway. I'd be grateful for any advise on how to debug a product build HotSpot with gdb instead of CLHSDB, where a lot of debugging support functions are not available in HotSpot itself and the symbols are inconvenient to access. >> >> On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne 2011. The "Future Plans" part sounds interesting. I think this plugin is the most visible way to use SA for most end users. It'd be great if it could be open sourced and made more extensible, say, embedding a variant of CLHSDB into this plugin. >> >> Regards, >> Kris Mok >> >> [1]: https://gist.github.com/1393698 >> On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen > wrote: >> >> I'm trying to figure out what the different front ends to SA are >> and how they differ. So far I have identified the following: >> >> HSDB - basic UI >> CLHSDB - command line version of HSDB >> BugSpot - improvement over HSDB ?? >> JSDB - JavaScript command line >> SOQL - Simple Object Query Language command line >> >> Have I missed any? >> >> What are your experiences with these? Which ones are most used? >> Should we maintain all of them? Can we consolidate them into one? >> Specifically: what is the difference between HSDB and BugSpot? >> >> I'd be happy for all and any feedback, >> /Staffan >> >> > From staffan.larsen at oracle.com Thu Feb 23 07:32:07 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 23 Feb 2012 16:32:07 +0100 Subject: SA frontends In-Reply-To: References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> Message-ID: <3168DFEC-81AB-4963-A74B-2773661F871F@oracle.com> Thanks for the pointer to SA Plugin - didn't know about that. Any idea how widely used it is? Thanks for the rest of the feedback as well, /Staffan On 22 feb 2012, at 10:34, Krystal Mok wrote: > Hi Staffan, > > There's at least another frontend, the SA Plugin for Visual VM. I think it only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't use stuff from BugSpot. > Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly SA frontends, but use the SA to implement their functionality. > > I use CLHSDB a lot when I poke around the internals of HotSpot. It's good for its purpose, except that history support is really weird, e.g. pressing up arrow give "^[[A". When I need commands not available in CLHSDB yet, I can write a JavaScript file and use "jsload" in CLHSDB to extend it with new commands. Example here: [1]. > > I seldom use JSDB directly, because the command style of CLHSDB works better, if the commands cover all the needs during a debugging session. When writing new commands for CLHSDB, sometimes I use the "jseval" command to try things out first, before actually writing them into a script file. That overlaps with what JSDB does, but of course prototyping in JSDB would be much nicer than in CLHSDB. > > On the top of my wishlist on CLHSDB, I'd wish for: > 1. better input support (something like jline would be great) > 2. AMD64 disassembler support (not frontend issue) > 3. live stepping/breakpointing support (not frontend issue) > > If 2 and 3 is implemented, I might be able to spend more time in CLHSDB, where sometimes I have to use a native debugger like gdb. But these aren't frontend issue anyway. I'd be grateful for any advise on how to debug a product build HotSpot with gdb instead of CLHSDB, where a lot of debugging support functions are not available in HotSpot itself and the symbols are inconvenient to access. > > On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne 2011. The "Future Plans" part sounds interesting. I think this plugin is the most visible way to use SA for most end users. It'd be great if it could be open sourced and made more extensible, say, embedding a variant of CLHSDB into this plugin. > > Regards, > Kris Mok > > [1]: https://gist.github.com/1393698 > > On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen wrote: > I'm trying to figure out what the different front ends to SA are and how they differ. So far I have identified the following: > > HSDB - basic UI > CLHSDB - command line version of HSDB > BugSpot - improvement over HSDB ?? > JSDB - JavaScript command line > SOQL - Simple Object Query Language command line > > Have I missed any? > > What are your experiences with these? Which ones are most used? Should we maintain all of them? Can we consolidate them into one? Specifically: what is the difference between HSDB and BugSpot? > > I'd be happy for all and any feedback, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120223/386851af/attachment.html From sundararajan.athijegannathan at oracle.com Thu Feb 23 08:27:46 2012 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 23 Feb 2012 21:57:46 +0530 Subject: SA frontends In-Reply-To: <8D856712-CE77-4228-BD85-BC45FF8F379C@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> <4F44C1D8.6000109@oracle.com> <8D856712-CE77-4228-BD85-BC45FF8F379C@oracle.com> Message-ID: <4F466902.9090108@oracle.com> I think current SA/hotspot developers are the best judges. I used to be part of serviceability team and worked on SA among other things in the past. AFAIK, SA suspend/resume was never really implemented or worked properly. If that is still thought to be useful, we may to see if we can improve BugSpot. Or else code could be merged b/w HotSpotAgent and BugSpotAgent. JSDB is a javascript shell with SA specific stuff exposed as script functions. With jsload/jseval in CLHSDB, we can do away with another tool doing doing script shell and improve CLHSDB as needed. SOQL's functionality is provided by taking heap dump and viewing it offline. My take is that a single integrated command line tool would be better. Thanks -Sundar Staffan Larsen wrote: > On 22 feb 2012, at 11:22, A. Sundararajan wrote: > > >> SA uses stop-the-world to debug "snapshot" of the process. BugSpot was supposed to be a SA model where you can pause/resume and keep looking at different snapshots (as well as use JDI to look at process state). But, it was never implemented that way. Over the years lot of stuff accumulated assuming the snapshot model as well. >> > > So what does BugSpot have that HSDB does not (and the other way around)? Could one of them be retired? > > >> And yes, JSDB may not be directly useful - but you can use most of functionality CLHSDB using script "load" as Kris mentioned. >> > > So maybe CLHSDB can be improved and JSDB retired? > > >> SOQL: Better option is to retrieve heap dump from core/process using jmap (or SA internals) and view it by jhat or VisualVM. >> > > Same thing here? > > Thanks for the feedback, > /Staffan > > >> -Sundar >> >> Krystal Mok wrote: >> >>> Hi Staffan, >>> >>> There's at least another frontend, the SA Plugin for Visual VM. I think it only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't use stuff from BugSpot. >>> Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly SA frontends, but use the SA to implement their functionality. >>> >>> I use CLHSDB a lot when I poke around the internals of HotSpot. It's good for its purpose, except that history support is really weird, e.g. pressing up arrow give "^[[A". When I need commands not available in CLHSDB yet, I can write a JavaScript file and use "jsload" in CLHSDB to extend it with new commands. Example here: [1]. >>> >>> I seldom use JSDB directly, because the command style of CLHSDB works better, if the commands cover all the needs during a debugging session. When writing new commands for CLHSDB, sometimes I use the "jseval" command to try things out first, before actually writing them into a script file. That overlaps with what JSDB does, but of course prototyping in JSDB would be much nicer than in CLHSDB. >>> >>> On the top of my wishlist on CLHSDB, I'd wish for: >>> 1. better input support (something like jline would be great) >>> 2. AMD64 disassembler support (not frontend issue) >>> 3. live stepping/breakpointing support (not frontend issue) >>> >>> If 2 and 3 is implemented, I might be able to spend more time in CLHSDB, where sometimes I have to use a native debugger like gdb. But these aren't frontend issue anyway. I'd be grateful for any advise on how to debug a product build HotSpot with gdb instead of CLHSDB, where a lot of debugging support functions are not available in HotSpot itself and the symbols are inconvenient to access. >>> >>> On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne 2011. The "Future Plans" part sounds interesting. I think this plugin is the most visible way to use SA for most end users. It'd be great if it could be open sourced and made more extensible, say, embedding a variant of CLHSDB into this plugin. >>> >>> Regards, >>> Kris Mok >>> >>> [1]: https://gist.github.com/1393698 >>> On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen > wrote: >>> >>> I'm trying to figure out what the different front ends to SA are >>> and how they differ. So far I have identified the following: >>> >>> HSDB - basic UI >>> CLHSDB - command line version of HSDB >>> BugSpot - improvement over HSDB ?? >>> JSDB - JavaScript command line >>> SOQL - Simple Object Query Language command line >>> >>> Have I missed any? >>> >>> What are your experiences with these? Which ones are most used? >>> Should we maintain all of them? Can we consolidate them into one? >>> Specifically: what is the difference between HSDB and BugSpot? >>> >>> I'd be happy for all and any feedback, >>> /Staffan >>> >>> >>> > > From rednaxelafx at gmail.com Thu Feb 23 08:30:00 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 24 Feb 2012 00:30:00 +0800 Subject: SA frontends In-Reply-To: <8D856712-CE77-4228-BD85-BC45FF8F379C@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> <4F44C1D8.6000109@oracle.com> <8D856712-CE77-4228-BD85-BC45FF8F379C@oracle.com> Message-ID: Hi Staffan, > So maybe CLHSDB can be improved and JSDB retired? Maybe, if the input experience of CLHSDB can be improved. It's awful to prototype new commands with JavaScript in CLHSDB, because the whole snippet of script is only allowed to span one single line, using "jseval". If it can at least let users enter scripts that span multiple lines... > Thanks for the pointer to SA Plugin - didn't know about that. Any idea how widely used it is? Don't know about that. I can't recall how I found this plugin in the first place. It's there in the available plugins list in VisualVM, so it should get a lot more exposure to end users, compared with other SA frontends. SA wasn't for end users to poke around anyway, and it wasn't available on Windows until a build of JDK 7, where a lot of end users like using GUI tools. And I guess the guys that work on the VM internals wouldn't really use this plugin a lot. But it could certainly be made more useful and friendly to end users, for those curious about the internals. For instance, the Oop Inspector in its current form, even though a user can enter an address to inspect a tree of objects, but it's no good if the user doesn't know beforehand the address of the object he/she wanted. I used a couple of hacks to get the address of an object I want (without modifying the VM), but that's really not for normal users. I didn't know the SA Plugin is open sourced already, until I read Poonam's reply in this thread. Hopefully it can get more traction in the future. Regards, Kris Mok On Thu, Feb 23, 2012 at 11:31 PM, Staffan Larsen wrote: > On 22 feb 2012, at 11:22, A. Sundararajan wrote: > > > SA uses stop-the-world to debug "snapshot" of the process. BugSpot was > supposed to be a SA model where you can pause/resume and keep looking at > different snapshots (as well as use JDI to look at process state). But, it > was never implemented that way. Over the years lot of stuff accumulated > assuming the snapshot model as well. > > So what does BugSpot have that HSDB does not (and the other way around)? > Could one of them be retired? > > > And yes, JSDB may not be directly useful - but you can use most of > functionality CLHSDB using script "load" as Kris mentioned. > > So maybe CLHSDB can be improved and JSDB retired? > > > SOQL: Better option is to retrieve heap dump from core/process using > jmap (or SA internals) and view it by jhat or VisualVM. > > Same thing here? > > Thanks for the feedback, > /Staffan > > > > > -Sundar > > > > Krystal Mok wrote: > >> Hi Staffan, > >> > >> There's at least another frontend, the SA Plugin for Visual VM. I think > it only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't > use stuff from BugSpot. > >> Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly > SA frontends, but use the SA to implement their functionality. > >> > >> I use CLHSDB a lot when I poke around the internals of HotSpot. It's > good for its purpose, except that history support is really weird, e.g. > pressing up arrow give "^[[A". When I need commands not available in CLHSDB > yet, I can write a JavaScript file and use "jsload" in CLHSDB to extend it > with new commands. Example here: [1]. > >> > >> I seldom use JSDB directly, because the command style of CLHSDB works > better, if the commands cover all the needs during a debugging session. > When writing new commands for CLHSDB, sometimes I use the "jseval" command > to try things out first, before actually writing them into a script file. > That overlaps with what JSDB does, but of course prototyping in JSDB would > be much nicer than in CLHSDB. > >> > >> On the top of my wishlist on CLHSDB, I'd wish for: > >> 1. better input support (something like jline would be great) > >> 2. AMD64 disassembler support (not frontend issue) > >> 3. live stepping/breakpointing support (not frontend issue) > >> > >> If 2 and 3 is implemented, I might be able to spend more time in > CLHSDB, where sometimes I have to use a native debugger like gdb. But these > aren't frontend issue anyway. I'd be grateful for any advise on how to > debug a product build HotSpot with gdb instead of CLHSDB, where a lot of > debugging support functions are not available in HotSpot itself and the > symbols are inconvenient to access. > >> > >> On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne > 2011. The "Future Plans" part sounds interesting. I think this plugin is > the most visible way to use SA for most end users. It'd be great if it > could be open sourced and made more extensible, say, embedding a variant of > CLHSDB into this plugin. > >> > >> Regards, > >> Kris Mok > >> > >> [1]: https://gist.github.com/1393698 > >> On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen < > staffan.larsen at oracle.com > wrote: > >> > >> I'm trying to figure out what the different front ends to SA are > >> and how they differ. So far I have identified the following: > >> > >> HSDB - basic UI > >> CLHSDB - command line version of HSDB > >> BugSpot - improvement over HSDB ?? > >> JSDB - JavaScript command line > >> SOQL - Simple Object Query Language command line > >> > >> Have I missed any? > >> > >> What are your experiences with these? Which ones are most used? > >> Should we maintain all of them? Can we consolidate them into one? > >> Specifically: what is the difference between HSDB and BugSpot? > >> > >> I'd be happy for all and any feedback, > >> /Staffan > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/5b0f9973/attachment-0001.html From frederic.parain at oracle.com Thu Feb 23 09:01:26 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 23 Feb 2012 18:01:26 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> Message-ID: <4F4670E6.3040407@oracle.com> No particular reason. But after thinking more about it, equals() should be a better choice, clearer code, and the length check in equals() implementation is likely to help performance of ObjectName's comparisons as ObjectNames are often long with a common section at the beginning. I've updated the webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ Thanks, Fred On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > Hi Frederic, > > Just curious - why are you checking string equality via compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From joe.darcy at oracle.com Thu Feb 23 09:53:29 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 Feb 2012 17:53:29 +0000 Subject: hg: jdk8/tl/langtools: 7148025: javac should not warn about InterrupttedException on the declaration of AutoCloseable itself Message-ID: <20120223175333.927C347658@hg.openjdk.java.net> Changeset: 3ad851a7e884 Author: darcy Date: 2012-02-23 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ad851a7e884 7148025: javac should not warn about InterrupttedException on the declaration of AutoCloseable itself Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java From schlosna at gmail.com Thu Feb 23 10:46:25 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 23 Feb 2012 13:46:25 -0500 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4670E6.3040407@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: On Thu, Feb 23, 2012 at 12:01 PM, Frederic Parain wrote: > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > Thanks, > > Fred Was the main bottleneck the contention on the interned string pool that prevented concurrent addition of ObjectNames? Are there other places within the JDK where use of intern() should be analyzed for similar scalability bottlenecks? I'm also curious what the heap implications are of no longer using interned strings. A minor nit is that the equals method could be simplified slightly, making it more clear that the canonical names must match for equality: @Override public boolean equals(Object object) { // same object case if (this == object) return true; // object is not an object name case if (!(object instanceof ObjectName)) return false; ObjectName on = (ObjectName) object; return _canonicalName.equals(on._canonicalName); } Thanks, Dave From david.holmes at oracle.com Thu Feb 23 13:53:05 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2012 07:53:05 +1000 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F465D07.5000302@oracle.com> References: <4F465D07.5000302@oracle.com> Message-ID: <4F46B541.50706@oracle.com> Hi Fred, java.lang.ObjectName? :) Need to fix that. So often we intern strings precisely so that equals() can use == to improve performance. It seems to me that this is a case of "fixing" something for one use-case without knowing what the impact will be on other use-cases! Is there perhaps a solution that makes String.intern more scalable? David ----- On 24/02/2012 1:36 AM, Frederic Parain wrote: > This a simple fix to solve CR 6988220: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > From keith.mcguigan at oracle.com Thu Feb 23 14:23:29 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 23 Feb 2012 17:23:29 -0500 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F46B541.50706@oracle.com> References: <4F465D07.5000302@oracle.com> <4F46B541.50706@oracle.com> Message-ID: <4F46BC61.8090803@oracle.com> Making String.intern() more scalable has been on our list of things-to-do for a long, long time. But, it's not trivial. Simply increasing the size of the hashtable is no good because we'd be upping our footprint unconditionally, so really we want a growing hashtable which is a bit more effort (though not impossible, of course, it just hasn't bubbled up to the top of the priority list). Another problem with using 'intern()' is that when you intern a string you're placing it into the permgen, and space there is at a premium. (no perm gen project will hopefully fix this soon). If you really want to use == instead of "equals()", you can use a java.util "set" or "map" data structure and stash all of your strings in there. Then you'll have canonicalized references that == will work upon, and you won't run into the intern() scalability (or concurrency) issues. -- - Keith On 2/23/2012 4:53 PM, David Holmes wrote: > Hi Fred, > > java.lang.ObjectName? :) Need to fix that. > > So often we intern strings precisely so that equals() can use == to > improve performance. > > It seems to me that this is a case of "fixing" something for one > use-case without knowing what the impact will be on other use-cases! > > Is there perhaps a solution that makes String.intern more scalable? > > David > ----- > > On 24/02/2012 1:36 AM, Frederic Parain wrote: >> This a simple fix to solve CR 6988220: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 >> >> The use of String.intern() in the ObjectName class prevents >> the class the scale well when more than 20K ObjectNames are >> managed. The fix simply removes the use of String.intern(), >> and uses regular String instead. The Object.equals() method >> is modified too to make a regular String comparison. The >> complexity of this method now depends on the length of >> the ObjectName's canonical name, and is not impacted any >> more by the number of ObjectName instances being handled. >> >> The Webrev: >> http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ >> >> I've tested this fix with the jdk_lang and jdk_management >> test suites. >> >> Thanks, >> >> Fred >> From rednaxelafx at gmail.com Thu Feb 23 18:08:42 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 24 Feb 2012 10:08:42 +0800 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F46BC61.8090803@oracle.com> References: <4F465D07.5000302@oracle.com> <4F46B541.50706@oracle.com> <4F46BC61.8090803@oracle.com> Message-ID: Hi Keith, > Another problem with using 'intern()' is that when you intern a string you're placing it into the permgen, and space there is at a premium. (no perm gen project will hopefully fix this soon). Actually that's fixed already, in 6962931 and a couple of related fixes later. - Kris On Fri, Feb 24, 2012 at 6:23 AM, Keith McGuigan wrote: > > Making String.intern() more scalable has been on our list of things-to-do > for a long, long time. But, it's not trivial. Simply increasing the size > of the hashtable is no good because we'd be upping our footprint > unconditionally, so really we want a growing hashtable which is a bit more > effort (though not impossible, of course, it just hasn't bubbled up to the > top of the priority list). > > Another problem with using 'intern()' is that when you intern a string > you're placing it into the permgen, and space there is at a premium. (no > perm gen project will hopefully fix this soon). > > If you really want to use == instead of "equals()", you can use a > java.util "set" or "map" data structure and stash all of your strings in > there. Then you'll have canonicalized references that == will work upon, > and you won't run into the intern() scalability (or concurrency) issues. > > -- > - Keith > > > > On 2/23/2012 4:53 PM, David Holmes wrote: > >> Hi Fred, >> >> java.lang.ObjectName? :) Need to fix that. >> >> So often we intern strings precisely so that equals() can use == to >> improve performance. >> >> It seems to me that this is a case of "fixing" something for one >> use-case without knowing what the impact will be on other use-cases! >> >> Is there perhaps a solution that makes String.intern more scalable? >> >> David >> ----- >> >> On 24/02/2012 1:36 AM, Frederic Parain wrote: >> >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220 >>> >>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/ >>> >>> I've tested this fix with the jdk_lang and jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/718b0f46/attachment.html From vitalyd at gmail.com Thu Feb 23 07:58:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 23 Feb 2012 10:58:47 -0500 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F465D07.5000302@oracle.com> References: <4F465D07.5000302@oracle.com> Message-ID: Hi Frederic, Just curious - why are you checking string equality via compareTo() instead of equals()? Thanks Sent from my phone On Feb 23, 2012 10:37 AM, "Frederic Parain" wrote: > This a simple fix to solve CR 6988220: > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220 > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/ > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120223/59bd0e33/attachment-0001.html From olivier.lagneau at oracle.com Thu Feb 23 10:52:16 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Thu, 23 Feb 2012 19:52:16 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4670E6.3040407@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: <4F468AE0.4030406@oracle.com> Hi Frederic, Performance and typo comments. Regarding performance of ObjectName.equals method, which is certainely a frequent call on ObjectNames, I think that using inner fields (Property array for canonical name and domain length) would be more efficient than using String.equals() on these potentially very long strings. Two differents objectNames may often have the same length with different key/properties values, and may often be different only on the last property of the canonical name. The Property array field ca_array (comparing length and property contents) and domain length are good candidates to filter out more efficiently different objectNames, knowing that String.equals will compare every single char of the two char arrays. So for performance purpose, I suggest to filter out different objectNames by doing inner comparisons in the following order : length of the two canonical names, then domain_length, then ca_array size, then its content, and lastly if all of this fails to filter out, then use String.equals. > _canonicalName = (new String(canonical_chars, 0, prop_index)); Typo : useless parentheses. Thanks, Olivier. -- Olivier Lagneau, olivier.lagneau at oracle.com Oracle, Grenoble Engineering Center - France Phone : +33 4 76 18 80 09 Fax : +33 4 76 18 80 23 Frederic Parain said on date 2/23/2012 6:01 PM: > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >> Hi Frederic, >> >> Just curious - why are you checking string equality via compareTo() >> instead of equals()? >> >> Thanks >> >> Sent from my phone >> >> On Feb 23, 2012 10:37 AM, "Frederic Parain" > > wrote: >> >> This a simple fix to solve CR 6988220: >> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >> >> >> The use of String.intern() in the ObjectName class prevents >> the class the scale well when more than 20K ObjectNames are >> managed. The fix simply removes the use of String.intern(), >> and uses regular String instead. The Object.equals() method >> is modified too to make a regular String comparison. The >> complexity of this method now depends on the length of >> the ObjectName's canonical name, and is not impacted any >> more by the number of ObjectName instances being handled. >> >> The Webrev: >> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >> >> >> I've tested this fix with the jdk_lang and jdk_management >> test suites. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120223/302546c4/attachment-0001.html From frederic.parain at oracle.com Fri Feb 24 00:34:20 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 09:34:20 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> Message-ID: <4F474B8C.5080302@oracle.com> I'm in favor of not adding complexity to ObjectName.equals(). The goal of this CR is to remove a bottleneck created by the use of String.intern() in ObjectName's constructors. This CR doesn't aim to optimize the ObjectName.equals() method. An application can define an optimized method to compare two ObjectNames based on its knowledge of the patterns used by its ObjectNames. However, there's no simple way to workaround the bottleneck created by the String.intern() call. The Ops-Center team has experimented the removal of String.intern() by providing their own implementation of ObjectName and playing with the bootclasspath, but this is not a solution easy to deploy in a production environment. Fred On 2/23/12 8:44 PM, Eamonn McManus wrote: > I am not sure it is worth the complexity of extra checks. Do you have > data showing that ObjectName.equals usually returns false? In a > successful HashMap lookup, for example, it will usually return true > since the equals method is used to guard against collisions, and > collisions are rare by design. Meanwhile, String.equals is intrinsic in > HotSpot so we may assume that it is highly optimized, and you are giving > up that optimization if you use other comparisons. > > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > Hi Frederic, > > Performance and typo comments. > > Regarding performance of ObjectName.equals method, which is certainely > a frequent call on ObjectNames, I think that using inner fields > (Property array for canonical name and domain length) would be more > efficient > than using String.equals() on these potentially very long strings. > > Two differents objectNames may often have the same length with > different key/properties values, and may often be different only > on the last property of the canonical name. > > The Property array field ca_array (comparing length and property > contents) > and domain length are good candidates to filter out more efficiently > different objectNames, knowing that String.equals will compare every > single char of the two char arrays. > > So for performance purpose, I suggest to filter out different > objectNames > by doing inner comparisons in the following order : length of the two > canonical names, then domain_length, then ca_array size, then its > content, > and lastly if all of this fails to filter out, then use String.equals. > > _canonicalName = (new String(canonical_chars, 0, prop_index)); > > Typo : useless parentheses. > > Thanks, > Olivier. > > -- Olivier Lagneau, olivier.lagneau at oracle.com > > Oracle, Grenoble Engineering Center - France > Phone : +33 4 76 18 80 09 Fax : > +33 4 76 18 80 23 > > > > > Frederic Parain said on date 2/23/2012 6:01 PM: > > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.01/ > > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > Hi Frederic, > > Just curious - why are you checking string equality via > compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > > >> wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=6988220 > > > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~____fparain/6988220/webrev.00/ > > > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > > > Email: Frederic.Parain at oracle.com > > > > > > > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri Feb 24 01:04:25 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 10:04:25 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F46BC61.8090803@oracle.com> References: <4F465D07.5000302@oracle.com> <4F46B541.50706@oracle.com> <4F46BC61.8090803@oracle.com> Message-ID: <4F475299.6010407@oracle.com> Making String.intern() more scalable doesn't seem to be a solution for short (or medium?) time frame. Even if the computation cost of ObjectName.equals() is increased by this fix, there's no performance measurement in favor or against this change. I've looked for benchmarks stressing the ObjectName class, but I haven't found one yet. Using java.util "Set" or "Map" introduces new issues, like the memory footprint and new synchronizations to protect consistency of the collection. The Ops-Center team is stuck with this scalability issue for two years now. They have identified the problem in JDK6 and we're not able to provide them with a solution for JDK7 or JDK8. David, I agree that I have no data about the impact on other use-cases, but I know that the use of String.intern() cannot be easily workaround. We can remove the use of String.intern() and if the performance of the new ObjectName.equals() method really becomes a performance bottleneck for other use-cases, them we can re-work this method to improve its performance. But I'd prefer not starting complex optimizations on a method without having real indication that it causes real performance issues. Fred On 2/23/12 11:23 PM, Keith McGuigan wrote: > > Making String.intern() more scalable has been on our list of > things-to-do for a long, long time. But, it's not trivial. Simply > increasing the size of the hashtable is no good because we'd be upping > our footprint unconditionally, so really we want a growing hashtable > which is a bit more effort (though not impossible, of course, it just > hasn't bubbled up to the top of the priority list). > > Another problem with using 'intern()' is that when you intern a string > you're placing it into the permgen, and space there is at a premium. (no > perm gen project will hopefully fix this soon). > > If you really want to use == instead of "equals()", you can use a > java.util "set" or "map" data structure and stash all of your strings in > there. Then you'll have canonicalized references that == will work upon, > and you won't run into the intern() scalability (or concurrency) issues. > > -- > - Keith > > > On 2/23/2012 4:53 PM, David Holmes wrote: >> Hi Fred, >> >> java.lang.ObjectName? :) Need to fix that. >> >> So often we intern strings precisely so that equals() can use == to >> improve performance. >> >> It seems to me that this is a case of "fixing" something for one >> use-case without knowing what the impact will be on other use-cases! >> >> Is there perhaps a solution that makes String.intern more scalable? >> >> David >> ----- >> >> On 24/02/2012 1:36 AM, Frederic Parain wrote: >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 >>> >>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ >>> >>> I've tested this fix with the jdk_lang and jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri Feb 24 01:06:05 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 10:06:05 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F475299.6010407@oracle.com> References: <4F475299.6010407@oracle.com> Message-ID: <4F4752FD.5000700@oracle.com> Making String.intern() more scalable doesn't seem to be a solution for short (or medium?) time frame. Even if the computation cost of ObjectName.equals() is increased by this fix, there's no performance measurement in favor or against this change. I've looked for benchmarks stressing the ObjectName class, but I haven't found one yet. Using java.util "Set" or "Map" introduces new issues, like the memory footprint and new synchronizations to protect consistency of the collection. The Ops-Center team is stuck with this scalability issue for two years now. They have identified the problem in JDK6 and we're not able to provide them with a solution for JDK7 or JDK8. David, I agree that I have no data about the impact on other use-cases, but I know that the use of String.intern() cannot be easily workaround. We can remove the use of String.intern() and if the performance of the new ObjectName.equals() method really becomes a performance bottleneck for other use-cases, them we can re-work this method to improve its performance. But I'd prefer not starting complex optimizations on a method without having real indication that it causes real performance issues. Fred On 2/23/12 11:23 PM, Keith McGuigan wrote: > > Making String.intern() more scalable has been on our list of > things-to-do for a long, long time. But, it's not trivial. Simply > increasing the size of the hashtable is no good because we'd be upping > our footprint unconditionally, so really we want a growing hashtable > which is a bit more effort (though not impossible, of course, it just > hasn't bubbled up to the top of the priority list). > > Another problem with using 'intern()' is that when you intern a string > you're placing it into the permgen, and space there is at a premium. (no > perm gen project will hopefully fix this soon). > > If you really want to use == instead of "equals()", you can use a > java.util "set" or "map" data structure and stash all of your strings in > there. Then you'll have canonicalized references that == will work upon, > and you won't run into the intern() scalability (or concurrency) issues. > > -- > - Keith > > > On 2/23/2012 4:53 PM, David Holmes wrote: >> Hi Fred, >> >> java.lang.ObjectName? :) Need to fix that. >> >> So often we intern strings precisely so that equals() can use == to >> improve performance. >> >> It seems to me that this is a case of "fixing" something for one >> use-case without knowing what the impact will be on other use-cases! >> >> Is there perhaps a solution that makes String.intern more scalable? >> >> David >> ----- >> >> On 24/02/2012 1:36 AM, Frederic Parain wrote: >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988220 >>> >>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ >>> >>> I've tested this fix with the jdk_lang and jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From dmytro_sheyko at hotmail.com Fri Feb 24 01:08:50 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 24 Feb 2012 12:08:50 +0300 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com>, Message-ID: Hi, Though "compareTo" tends to be less efficient than "equals", it offers better type safety. When we (mistakenly!) compare objects of different type, "equals" silently accepts parameter of wrong type, but returns false. Comparison with "compareTo" is rejected by compiler. Consider, String string = ... Date date = ... if (string.equals(date)) { // always false } if (string.compareTo(date) == 0) { // compilation error } Regards, Dmytro > Date: Thu, 23 Feb 2012 10:58:47 -0500 > Subject: Re: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale > From: vitalyd at gmail.com > To: frederic.parain at oracle.com > CC: serviceability-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Hi Frederic, > > Just curious - why are you checking string equality via compareTo() instead > of equals()? > > Thanks > > Sent from my phone > On Feb 23, 2012 10:37 AM, "Frederic Parain" > wrote: > > > This a simple fix to solve CR 6988220: > > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6988220 > > > > The use of String.intern() in the ObjectName class prevents > > the class the scale well when more than 20K ObjectNames are > > managed. The fix simply removes the use of String.intern(), > > and uses regular String instead. The Object.equals() method > > is modified too to make a regular String comparison. The > > complexity of this method now depends on the length of > > the ObjectName's canonical name, and is not impacted any > > more by the number of ObjectName instances being handled. > > > > The Webrev: > > http://cr.openjdk.java.net/~**fparain/6988220/webrev.00/ > > > > I've tested this fix with the jdk_lang and jdk_management > > test suites. > > > > Thanks, > > > > Fred > > > > -- > > Frederic Parain - Oracle > > Grenoble Engineering Center - France > > Phone: +33 4 76 18 81 17 > > Email: Frederic.Parain at oracle.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/fd7c3bf7/attachment.html From sean.coffey at oracle.com Fri Feb 24 01:11:01 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 24 Feb 2012 09:11:01 +0000 Subject: hg: jdk8/tl/jdk: 7133138: Improve io performance around timezone lookups Message-ID: <20120224091125.C4DCC47689@hg.openjdk.java.net> Changeset: a589a8dbde79 Author: coffeys Date: 2012-02-24 09:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a589a8dbde79 7133138: Improve io performance around timezone lookups Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java From frederic.parain at oracle.com Fri Feb 24 01:13:43 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 24 Feb 2012 10:13:43 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> Message-ID: <4F4754C7.4010007@oracle.com> On 2/23/12 7:46 PM, David Schlosnagle wrote: > Was the main bottleneck the contention on the interned string pool > that prevented concurrent addition of ObjectNames? Are there other > places within the JDK where use of intern() should be analyzed for > similar scalability bottlenecks? I'm also curious what the heap > implications are of no longer using interned strings. I haven't looked for similar use of intern() within the JDK. However, the scalability issue of String.intern() is known for a long term, but the fix is not that simple, as Keith explained, this is why it has been delayed for a long time due to other higher priority tasks. > A minor nit is that the equals method could be simplified slightly, > making it more clear that the canonical names must match for equality: > > @Override > public boolean equals(Object object) { > // same object case > if (this == object) return true; > > // object is not an object name case > if (!(object instanceof ObjectName)) return false; > ObjectName on = (ObjectName) object; > return _canonicalName.equals(on._canonicalName); > } Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From sean.coffey at oracle.com Fri Feb 24 01:16:34 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 24 Feb 2012 09:16:34 +0000 Subject: hg: jdk8/tl/jdk: 7144488: Infinite recursion for some equals tests in Collections Message-ID: <20120224091644.B9B114768A@hg.openjdk.java.net> Changeset: 0a350fb8b174 Author: coffeys Date: 2012-02-24 09:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a350fb8b174 7144488: Infinite recursion for some equals tests in Collections Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EqualsTest.java From olivier.lagneau at oracle.com Fri Feb 24 03:38:59 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 24 Feb 2012 12:38:59 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> Message-ID: <4F4776D3.6010901@oracle.com> Hi ?amonn, Eamonn McManus said on date 2/23/2012 8:44 PM: > I am not sure it is worth the complexity of extra checks. Do you have > data showing that ObjectName.equals usually returns false?In a > successful HashMap lookup, for example, it will usually return true > since the equals method is used to guard against collisions, and > collisions are rare by design. Meanwhile, String.equals is intrinsic > in HotSpot so we may assume that it is highly optimized, and you are > giving up that optimization if you use other comparisons. Don't have this kind of data indeed. I don't know of any benchmark/data about usage of ObjectName.equals() in most applications. That would be needed to evaluate the exact impact of the change. And I agree with the argument that usual semantics of an equals call is to check for equality, not the difference. My argument is mainly that we are moving from comparing identity to equality. Thus there will be an impact on the throughput of equals, possibly impacting some applications. Olivier. > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > Hi Frederic, > > Performance and typo comments. > > Regarding performance of ObjectName.equals method, which is certainely > a frequent call on ObjectNames, I think that using inner fields > (Property array for canonical name and domain length) would be > more efficient > than using String.equals() on these potentially very long strings. > > Two differents objectNames may often have the same length with > different key/properties values, and may often be different only > on the last property of the canonical name. > > The Property array field ca_array (comparing length and property > contents) > and domain length are good candidates to filter out more efficiently > different objectNames, knowing that String.equals will compare every > single char of the two char arrays. > > So for performance purpose, I suggest to filter out different > objectNames > by doing inner comparisons in the following order : length of the two > canonical names, then domain_length, then ca_array size, then its > content, > and lastly if all of this fails to filter out, then use String.equals. > > _canonicalName = (new String(canonical_chars, 0, prop_index)); > > Typo : useless parentheses. > > Thanks, > Olivier. > > -- Olivier Lagneau, olivier.lagneau at oracle.com > > Oracle, Grenoble Engineering Center - France > Phone : +33 4 76 18 80 09 Fax > : +33 4 76 18 80 23 > > > > > Frederic Parain said on date 2/23/2012 6:01 PM: > > No particular reason. But after thinking more about it, > equals() should be a better choice, clearer code, and > the length check in equals() implementation is likely > to help performance of ObjectName's comparisons as > ObjectNames are often long with a common section at the > beginning. > > I've updated the webrev: > http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > > > Thanks, > > Fred > > On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > Hi Frederic, > > Just curious - why are you checking string equality via > compareTo() > instead of equals()? > > Thanks > > Sent from my phone > > On Feb 23, 2012 10:37 AM, "Frederic Parain" > > >> wrote: > > This a simple fix to solve CR 6988220: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > > > The use of String.intern() in the ObjectName class prevents > the class the scale well when more than 20K ObjectNames are > managed. The fix simply removes the use of String.intern(), > and uses regular String instead. The Object.equals() method > is modified too to make a regular String comparison. The > complexity of this method now depends on the length of > the ObjectName's canonical name, and is not impacted any > more by the number of ObjectName instances being handled. > > The Webrev: > http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > > > > > I've tested this fix with the jdk_lang and jdk_management > test suites. > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > > > Email: Frederic.Parain at oracle.com > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/dd55eb46/attachment.html From tomas.hurka at googlemail.com Fri Feb 24 04:32:49 2012 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Fri, 24 Feb 2012 13:32:49 +0100 Subject: SA frontends In-Reply-To: <4F45DA19.4060207@oracle.com> References: <41FF608B-D6F6-445D-8B1E-62C14A2C7BA7@oracle.com> <4F45DA19.4060207@oracle.com> Message-ID: Hi Poonam, On 23 Feb 2012, at 07:18, Poonam Bajaj wrote: > > SA-Plugin for VisualVM uses HotspotAgent - SA interface provided by class sun.jvm.hotspot.HotSpotAgent. SA-Plugin uses the attach/detach functionality provided by this class and it uses other SA classes (e.g. sun.jvm.hotspot.runtime.*, sun.jvm.hotspot.ui.*) to extract and display data in VisualVM views. > > SA-Plugin code is available in the VisualVM source base under 'plugins' suite. Instructions to get the code: http://visualvm.java.net/build.html. VisualVM is a project on java.net and I think members of the project having contributor role should be able to contribute to the project. In addition to SA-Plugin, VisualVM uses SA when working with the core dumps. It is also uses SA as a last resort for getting data (system properties, thread dump, etc.) from monitored application. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From olivier.lagneau at oracle.com Fri Feb 24 07:21:05 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 24 Feb 2012 16:21:05 +0100 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F4776D3.6010901@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> Message-ID: <4F47AAE1.1020705@oracle.com> I think I have not been clear enough here. I Agree with Eammon's argument, and anyway ok with this change. Olivier. Olivier Lagneau said on date 2/24/2012 12:38 PM: > Hi ?amonn, > > Eamonn McManus said on date 2/23/2012 8:44 PM: >> I am not sure it is worth the complexity of extra checks. Do you have >> data showing that ObjectName.equals usually returns false?In a >> successful HashMap lookup, for example, it will usually return true >> since the equals method is used to guard against collisions, and >> collisions are rare by design. Meanwhile, String.equals is intrinsic >> in HotSpot so we may assume that it is highly optimized, and you are >> giving up that optimization if you use other comparisons. > Don't have this kind of data indeed. I don't know of any > benchmark/data about usage of ObjectName.equals() > in most applications. That would be needed to evaluate the exact > impact of the change. > And I agree with the argument that usual semantics of an equals call > is to check for equality, > not the difference. > > My argument is mainly that we are moving from comparing identity to > equality. > Thus there will be an impact on the throughput of equals, possibly > impacting > some applications. > > Olivier. > >> ?amonn >> >> >> On 23 February 2012 10:52, Olivier Lagneau >> > wrote: >> >> Hi Frederic, >> >> Performance and typo comments. >> >> Regarding performance of ObjectName.equals method, which is >> certainely >> a frequent call on ObjectNames, I think that using inner fields >> (Property array for canonical name and domain length) would be >> more efficient >> than using String.equals() on these potentially very long strings. >> >> Two differents objectNames may often have the same length with >> different key/properties values, and may often be different only >> on the last property of the canonical name. >> >> The Property array field ca_array (comparing length and property >> contents) >> and domain length are good candidates to filter out more efficiently >> different objectNames, knowing that String.equals will compare every >> single char of the two char arrays. >> >> So for performance purpose, I suggest to filter out different >> objectNames >> by doing inner comparisons in the following order : length of the >> two >> canonical names, then domain_length, then ca_array size, then its >> content, >> and lastly if all of this fails to filter out, then use >> String.equals. >> >> _canonicalName = (new String(canonical_chars, 0, prop_index)); >> >> Typo : useless parentheses. >> >> Thanks, >> Olivier. >> >> -- Olivier Lagneau, olivier.lagneau at oracle.com >> >> Oracle, Grenoble Engineering Center - France >> Phone : +33 4 76 18 80 09 Fax >> : +33 4 76 18 80 23 >> >> >> >> >> Frederic Parain said on date 2/23/2012 6:01 PM: >> >> No particular reason. But after thinking more about it, >> equals() should be a better choice, clearer code, and >> the length check in equals() implementation is likely >> to help performance of ObjectName's comparisons as >> ObjectNames are often long with a common section at the >> beginning. >> >> I've updated the webrev: >> http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ >> >> >> Thanks, >> >> Fred >> >> On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >> >> Hi Frederic, >> >> Just curious - why are you checking string equality via >> compareTo() >> instead of equals()? >> >> Thanks >> >> Sent from my phone >> >> On Feb 23, 2012 10:37 AM, "Frederic Parain" >> > >> > >> wrote: >> >> This a simple fix to solve CR 6988220: >> >> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >> >> >> The use of String.intern() in the ObjectName class >> prevents >> the class the scale well when more than 20K >> ObjectNames are >> managed. The fix simply removes the use of >> String.intern(), >> and uses regular String instead. The Object.equals() >> method >> is modified too to make a regular String comparison. The >> complexity of this method now depends on the length of >> the ObjectName's canonical name, and is not impacted any >> more by the number of ObjectName instances being handled. >> >> The Webrev: >> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >> >> > > >> >> I've tested this fix with the jdk_lang and jdk_management >> test suites. >> >> Thanks, >> >> Fred >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> >> >> Email: Frederic.Parain at oracle.com >> >> > > >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/b3d59131/attachment-0001.html From daniel.daugherty at oracle.com Fri Feb 24 07:33:15 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Feb 2012 08:33:15 -0700 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47AAE1.1020705@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> Message-ID: <4F47ADBB.5070701@oracle.com> Just FYI: I haven't seen ?amonn's posting come in. Just replies to his posting. This may mean that other comments are stuck in the ether somewhere... I suspect that the OpenJDK list server is again having issues... Dan On 2/24/12 8:21 AM, Olivier Lagneau wrote: > I think I have not been clear enough here. > > I Agree with Eammon's argument, and anyway ok with this change. > > Olivier. > > > Olivier Lagneau said on date 2/24/2012 12:38 PM: >> Hi ?amonn, >> >> Eamonn McManus said on date 2/23/2012 8:44 PM: >>> I am not sure it is worth the complexity of extra checks. Do you >>> have data showing that ObjectName.equals usually returns false?In a >>> successful HashMap lookup, for example, it will usually return true >>> since the equals method is used to guard against collisions, and >>> collisions are rare by design. Meanwhile, String.equals is intrinsic >>> in HotSpot so we may assume that it is highly optimized, and you are >>> giving up that optimization if you use other comparisons. >> Don't have this kind of data indeed. I don't know of any >> benchmark/data about usage of ObjectName.equals() >> in most applications. That would be needed to evaluate the exact >> impact of the change. >> And I agree with the argument that usual semantics of an equals call >> is to check for equality, >> not the difference. >> >> My argument is mainly that we are moving from comparing identity to >> equality. >> Thus there will be an impact on the throughput of equals, possibly >> impacting >> some applications. >> >> Olivier. >> >>> ?amonn >>> >>> >>> On 23 February 2012 10:52, Olivier Lagneau >>> > wrote: >>> >>> Hi Frederic, >>> >>> Performance and typo comments. >>> >>> Regarding performance of ObjectName.equals method, which is >>> certainely >>> a frequent call on ObjectNames, I think that using inner fields >>> (Property array for canonical name and domain length) would be >>> more efficient >>> than using String.equals() on these potentially very long strings. >>> >>> Two differents objectNames may often have the same length with >>> different key/properties values, and may often be different only >>> on the last property of the canonical name. >>> >>> The Property array field ca_array (comparing length and property >>> contents) >>> and domain length are good candidates to filter out more >>> efficiently >>> different objectNames, knowing that String.equals will compare >>> every >>> single char of the two char arrays. >>> >>> So for performance purpose, I suggest to filter out different >>> objectNames >>> by doing inner comparisons in the following order : length of >>> the two >>> canonical names, then domain_length, then ca_array size, then its >>> content, >>> and lastly if all of this fails to filter out, then use >>> String.equals. >>> >>> _canonicalName = (new String(canonical_chars, 0, prop_index)); >>> >>> Typo : useless parentheses. >>> >>> Thanks, >>> Olivier. >>> >>> -- Olivier Lagneau, olivier.lagneau at oracle.com >>> >>> Oracle, Grenoble Engineering Center - France >>> Phone : +33 4 76 18 80 09 Fax >>> : +33 4 76 18 80 23 >>> >>> >>> >>> >>> Frederic Parain said on date 2/23/2012 6:01 PM: >>> >>> No particular reason. But after thinking more about it, >>> equals() should be a better choice, clearer code, and >>> the length check in equals() implementation is likely >>> to help performance of ObjectName's comparisons as >>> ObjectNames are often long with a common section at the >>> beginning. >>> >>> I've updated the webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ >>> >>> >>> Thanks, >>> >>> Fred >>> >>> On 2/23/12 4:58 PM, Vitaly Davidovich wrote: >>> >>> Hi Frederic, >>> >>> Just curious - why are you checking string equality via >>> compareTo() >>> instead of equals()? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Feb 23, 2012 10:37 AM, "Frederic Parain" >>> >> >>> >> >> wrote: >>> >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 >>> >>> >>> The use of String.intern() in the ObjectName class >>> prevents >>> the class the scale well when more than 20K >>> ObjectNames are >>> managed. The fix simply removes the use of >>> String.intern(), >>> and uses regular String instead. The Object.equals() >>> method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being >>> handled. >>> >>> The Webrev: >>> http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ >>> >>> >> > >>> >>> I've tested this fix with the jdk_lang and >>> jdk_management >>> test suites. >>> >>> Thanks, >>> >>> Fred >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> >>> >>> Email: Frederic.Parain at oracle.com >>> >>> >> > >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/6dd8915a/attachment.html From eamonn at mcmanus.net Fri Feb 24 08:06:55 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 24 Feb 2012 10:06:55 -0600 Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47ADBB.5070701@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> <4F47ADBB.5070701@oracle.com> Message-ID: Hi Dan, I got a bounce from serviceability-dev because I wasn't subscribed to it, but the message went out to core-libs-dev because I was subscribed to that. That probably explains what you saw. Regards, ?amonn On 24 February 2012 09:33, Daniel D. Daugherty wrote: > > Just FYI: I haven't seen ?amonn's posting come in. Just replies to > his posting. This may mean that other comments are stuck in the > ether somewhere... > > I suspect that the OpenJDK list server is again having issues... > > Dan > > > On 2/24/12 8:21 AM, Olivier Lagneau wrote: > > I think I have not been clear enough here. > > I Agree with Eammon's argument, and anyway ok with this change. > > Olivier. > > > Olivier Lagneau said? on date 2/24/2012 12:38 PM: > > Hi ?amonn, > > Eamonn McManus said? on date 2/23/2012 8:44 PM: > > I am not sure it is worth the complexity of extra checks. Do you have data showing that ObjectName.equals usually returns false?In a successful HashMap lookup, for example, it will usually return true since the equals method is used to guard against collisions, and collisions are rare by design. Meanwhile, String.equals is intrinsic in HotSpot so we may assume that it is highly optimized, and you are giving up that optimization if you use other comparisons. > > Don't have this kind of data indeed. I don't know of any benchmark/data about usage of ObjectName.equals() > in most applications. That would be needed to evaluate the exact impact of the change. > And I agree with the argument that usual semantics of an equals call is to check for equality, > not the difference. > > My argument is mainly that we are moving from comparing identity to equality. > Thus there will be an impact on the throughput of equals, possibly impacting > some applications. > > Olivier. > > ?amonn > > > On 23 February 2012 10:52, Olivier Lagneau > wrote: > > ??? Hi Frederic, > > ??? Performance and typo comments. > > ??? Regarding performance of ObjectName.equals method, which is certainely > ??? a frequent call on ObjectNames, I think that using inner fields > ??? (Property array for canonical name and domain length) would be > ??? more efficient > ??? than using String.equals() on these potentially very long strings. > > ??? Two differents objectNames may often have the same length with > ??? different key/properties values, and may often be different only > ??? on the last property of the canonical name. > > ??? The Property array field ca_array (comparing length and property > ??? contents) > ??? and domain length are good candidates to filter out more efficiently > ??? different objectNames, knowing that String.equals will compare every > ??? single char of the two char arrays. > > ??? So for performance purpose, I suggest to filter out different > ??? objectNames > ??? by doing inner comparisons in the following order : length of the two > ??? canonical names, then domain_length, then ca_array size, then its > ??? content, > ??? and lastly if all of this fails to filter out, then use String.equals. > > ???????? _canonicalName = (new String(canonical_chars, 0, prop_index)); > > ??? Typo : useless parentheses. > > ??? Thanks, > ??? Olivier. > > ??? -- Olivier Lagneau, olivier.lagneau at oracle.com > ??? > ??? Oracle, Grenoble Engineering Center - France > ??? Phone : +33 4 76 18 80 09 Fax > ??? : +33 4 76 18 80 23 > > > > > ??? Frederic Parain said? on date 2/23/2012 6:01 PM: > > ??????? No particular reason. But after thinking more about it, > ??????? equals() should be a better choice, clearer code, and > ??????? the length check in equals() implementation is likely > ??????? to help performance of ObjectName's comparisons as > ??????? ObjectNames are often long with a common section at the > ??????? beginning. > > ??????? I've updated the webrev: > ??????? http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ > ??????? > > ??????? Thanks, > > ??????? Fred > > ??????? On 2/23/12 4:58 PM, Vitaly Davidovich wrote: > > ??????????? Hi Frederic, > > ??????????? Just curious - why are you checking string equality via > ??????????? compareTo() > ??????????? instead of equals()? > > ??????????? Thanks > > ??????????? Sent from my phone > > ??????????? On Feb 23, 2012 10:37 AM, "Frederic Parain" > ??????????? ??????????? > ??????????? ??????????? >> wrote: > > ?????????????? This a simple fix to solve CR 6988220: > ??????????? http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=6988220 > ??????????? > > ?????????????? The use of String.intern() in the ObjectName class prevents > ?????????????? the class the scale well when more than 20K ObjectNames are > ?????????????? managed. The fix simply removes the use of String.intern(), > ?????????????? and uses regular String instead. The Object.equals() method > ?????????????? is modified too to make a regular String comparison. The > ?????????????? complexity of this method now depends on the length of > ?????????????? the ObjectName's canonical name, and is not impacted any > ?????????????? more by the number of ObjectName instances being handled. > > ?????????????? The Webrev: > ??????????? http://cr.openjdk.java.net/~__fparain/6988220/webrev.00/ > ??????????? > ??????????? ??????????? > > > ?????????????? I've tested this fix with the jdk_lang and jdk_management > ?????????????? test suites. > > ?????????????? Thanks, > > ?????????????? Fred > > ?????????????? -- > ?????????????? Frederic Parain - Oracle > ?????????????? Grenoble Engineering Center - France > ?????????????? Phone: +33 4 76 18 81 17 > ??????????? > ??????????? > ?????????????? Email: Frederic.Parain at oracle.com > ??????????? > ??????????? ??????????? > > > > > > > From staffan.larsen at oracle.com Fri Feb 24 08:12:19 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Feb 2012 17:12:19 +0100 Subject: RFR(S): 7079093 & 7073626: cygwin problems in tests Message-ID: Please review the following changes: webrev: http://cr.openjdk.java.net/~sla/7073626/webrev.00/ This is a combo review for the following two bugs (although I will push as two changes): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079093 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073626 The first problem is to recognize cygwin as a valid platform and to set up the SystemRoot environment variable (which can be called SYSTEMROOT) in some cases. The second problem is that some versions of cygwin (or at least some installations of cygwin) will add extra newlines when cat:ing files, so I remove those. The fixes passes JRPT runs. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/1e6fd8b0/attachment.html From Alan.Bateman at oracle.com Fri Feb 24 08:35:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Feb 2012 16:35:42 +0000 Subject: RFR(S): 7079093 & 7073626: cygwin problems in tests In-Reply-To: References: Message-ID: <4F47BC5E.2040208@oracle.com> On 24/02/2012 16:12, Staffan Larsen wrote: > Please review the following changes: > > webrev: http://cr.openjdk.java.net/~sla/7073626/webrev.00/ > > > This is a combo review for the following two bugs (although I will > push as two changes): > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079093 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073626 > > > The first problem is to recognize cygwin as a valid platform and to > set up the SystemRoot environment variable (which can be called > SYSTEMROOT) in some cases. > > The second problem is that some versions of cygwin (or at least some > installations of cygwin) will add extra newlines when cat:ing files, > so I remove those. > Looks good to me. I see you've commented out ManifestTest.sh in the ProblemList and I assume it can be removed completely. -Alan ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/c783b992/attachment.html From staffan.larsen at oracle.com Fri Feb 24 08:37:54 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Feb 2012 17:37:54 +0100 Subject: RFR(S): 7079093 & 7073626: cygwin problems in tests In-Reply-To: <4F47BC5E.2040208@oracle.com> References: <4F47BC5E.2040208@oracle.com> Message-ID: <750258F1-5A69-4255-9ACB-A45722BA1CA3@oracle.com> On 24 feb 2012, at 17:35, Alan Bateman wrote: > Looks good to me. I see you've commented out ManifestTest.sh in the ProblemList and I assume it can be removed completely. Yes, will fix. Thanks, /Staffan From iris.clark at oracle.com Fri Feb 24 08:05:32 2012 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 24 Feb 2012 08:05:32 -0800 (PST) Subject: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale In-Reply-To: <4F47ADBB.5070701@oracle.com> References: <4F465D07.5000302@oracle.com> <4F4670E6.3040407@oracle.com> <4F468AE0.4030406@oracle.com> <4F4776D3.6010901@oracle.com> <4F47AAE1.1020705@oracle.com> <4F47ADBB.5070701@oracle.com> Message-ID: Hi, Dan. > Just FYI: I haven't seen ?amonn's posting come in. Just replies to his > posting. This may mean that other comments are stuck in the ether > somewhere... > > I suspect that the OpenJDK list server is again having issues... I just checked the core-libs-dev admin interface to see if anything was waiting for moderation, but there wasn't anything. (Not that I'd expect that to be the case for messages from ?amonn.) Must be a failure at some other level... Sorry. iris From serguei.spitsyn at oracle.com Fri Feb 24 10:04:31 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Feb 2012 10:04:31 -0800 Subject: RFR(S): 7079093 & 7073626: cygwin problems in tests In-Reply-To: References: Message-ID: <4F47D12F.6040302@oracle.com> Looks good. A copyright comment year must be 2012. Thanks, Serguei On 2/24/12 8:12 AM, Staffan Larsen wrote: > Please review the following changes: > > webrev: http://cr.openjdk.java.net/~sla/7073626/webrev.00/ > > > This is a combo review for the following two bugs (although I will > push as two changes): > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079093 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073626 > > > The first problem is to recognize cygwin as a valid platform and to > set up the SystemRoot environment variable (which can be called > SYSTEMROOT) in some cases. > > The second problem is that some versions of cygwin (or at least some > installations of cygwin) will add extra newlines when cat:ing files, > so I remove those. > > The fixes passes JRPT runs. > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120224/b738e440/attachment.html From jonathan.gibbons at oracle.com Fri Feb 24 10:40:46 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 24 Feb 2012 18:40:46 +0000 Subject: hg: jdk8/tl/langtools: 7137836: tidy up Names.java Message-ID: <20120224184049.000AA4769A@hg.openjdk.java.net> Changeset: e6b5c3aff85c Author: jjg Date: 2012-02-24 10:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6b5c3aff85c 7137836: tidy up Names.java Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/util/Names.java From staffan.larsen at oracle.com Fri Feb 24 11:06:28 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 24 Feb 2012 19:06:28 +0000 Subject: hg: jdk8/tl/jdk: 7073626: RmiBootstrapTest.sh and RmiSslBootstrapTest.sh fail under Cygwin Message-ID: <20120224190646.BA9E74769B@hg.openjdk.java.net> Changeset: 585f2c72d042 Author: sla Date: 2012-02-24 20:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/585f2c72d042 7073626: RmiBootstrapTest.sh and RmiSslBootstrapTest.sh fail under Cygwin Summary: Detect and handle cygwin correctly Reviewed-by: alanb, sspitsyn ! test/ProblemList.txt ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh From staffan.larsen at oracle.com Fri Feb 24 11:09:54 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 24 Feb 2012 19:09:54 +0000 Subject: hg: jdk8/tl/jdk: 7079093: TEST_BUG: java/lang/instrument/ManifestTest.sh fails with cygwin Message-ID: <20120224191004.765204769C@hg.openjdk.java.net> Changeset: 4893a89b4916 Author: sla Date: 2012-02-24 20:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4893a89b4916 7079093: TEST_BUG: java/lang/instrument/ManifestTest.sh fails with cygwin Summary: Work around problems in some cygwin installations Reviewed-by: alanb, sspitsyn ! test/ProblemList.txt ! test/java/lang/instrument/ManifestTest.sh From Dmitry.Samersoff at oracle.com Fri Feb 24 11:46:27 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 24 Feb 2012 23:46:27 +0400 Subject: RFR(S): 7079093 & 7073626: cygwin problems in tests In-Reply-To: References: Message-ID: <4F47E913.8070501@oracle.com> Staffan, Looks good for me! -Dmitry On 2012-02-24 20:12, Staffan Larsen wrote: > Please review the following changes: > > webrev: http://cr.openjdk.java.net/~sla/7073626/webrev.00/ > > This is a combo review for the following two bugs (although I will push > as two changes): > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7079093 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073626 > > > The first problem is to recognize cygwin as a valid platform and to set > up the SystemRoot environment variable (which can be called SYSTEMROOT) > in some cases. > > The second problem is that some versions of cygwin (or at least some > installations of cygwin) will add extra newlines when cat:ing files, so > I remove those. > > The fixes passes JRPT runs. > > Thanks, > /Staffan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Sat Feb 25 01:43:13 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Sat, 25 Feb 2012 09:43:13 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7148126: ConstantPoolCacheEntry::print prints to wrong stream Message-ID: <20120225094317.A1E78476B7@hg.openjdk.java.net> Changeset: f096e1b74d85 Author: dholmes Date: 2012-02-25 01:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f096e1b74d85 7148126: ConstantPoolCacheEntry::print prints to wrong stream Summary: Should print to passed in stream not tty Reviewed-by: dholmes, never Contributed-by: Krystal Mok ! src/share/vm/oops/cpCacheOop.cpp From alan.bateman at oracle.com Sun Feb 26 09:26:47 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 26 Feb 2012 17:26:47 +0000 Subject: hg: jdk8/tl/jdk: 7148921: More ProblemList updates (2/2012) Message-ID: <20120226172716.20F87476C2@hg.openjdk.java.net> Changeset: 434e680b444f Author: alanb Date: 2012-02-26 17:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/434e680b444f 7148921: More ProblemList updates (2/2012) Reviewed-by: chegar ! test/ProblemList.txt From dmitriy.samersoff at oracle.com Mon Feb 27 03:21:51 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Mon, 27 Feb 2012 11:21:51 +0000 Subject: hg: jdk8/tl/jdk: 7110104: It should be possible to stop and start JMX Agent at runtime Message-ID: <20120227112243.C879E476CF@hg.openjdk.java.net> Changeset: 1e737abbff6f Author: dsamersoff Date: 2012-02-27 15:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e737abbff6f 7110104: It should be possible to stop and start JMX Agent at runtime Summary: Added a capability to start and stop JMX Agent by jcmd Reviewed-by: acorn, mchung ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/AgentConfigurationError.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/resources/agent.properties ! test/sun/management/AgentCheckTest.java + test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java + test/sun/management/jmxremote/startstop/JMXStartStopTest.java + test/sun/management/jmxremote/startstop/JMXStartStopTest.sh + test/sun/management/jmxremote/startstop/REMOTE_TESTING.txt + test/sun/management/jmxremote/startstop/management_cl.properties + test/sun/management/jmxremote/startstop/management_jcmd.properties From sean.mullan at oracle.com Mon Feb 27 10:51:45 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 27 Feb 2012 18:51:45 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120227185215.8C0DA476D6@hg.openjdk.java.net> Changeset: 805fc337bbe8 Author: mullan Date: 2012-02-27 11:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/805fc337bbe8 7147830: NullPointerException in java.security.Policy.implies() when the ProtectionDomain has a null code sou Reviewed-by: vinnie ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/NullCodeSource.java Changeset: cdf6184a7d5c Author: mullan Date: 2012-02-27 13:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf6184a7d5c Merge From mike.duigou at oracle.com Mon Feb 27 18:20:50 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 28 Feb 2012 02:20:50 +0000 Subject: hg: jdk8/tl/jdk: 7143162: Allow disable building of jdk demos and samples Message-ID: <20120228022101.E996C476D9@hg.openjdk.java.net> Changeset: 323abe0e8973 Author: mduigou Date: 2012-02-27 18:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/323abe0e8973 7143162: Allow disable building of jdk demos and samples Reviewed-by: ohair ! make/Makefile ! make/common/Release.gmk ! make/common/shared/Sanity-Settings.gmk From mike.duigou at oracle.com Mon Feb 27 18:22:59 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 28 Feb 2012 02:22:59 +0000 Subject: hg: jdk8/tl: 7143162: Allow disable building of jdk demos and samples Message-ID: <20120228022259.4B308476DA@hg.openjdk.java.net> Changeset: 28f2fe471725 Author: mduigou Date: 2012-02-27 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28f2fe471725 7143162: Allow disable building of jdk demos and samples Reviewed-by: ohair ! make/sanity-rules.gmk From Dmitry.Samersoff at oracle.com Tue Feb 28 03:54:58 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Feb 2012 15:54:58 +0400 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4BEC02.20902@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> Message-ID: <4F4CC092.7020007@oracle.com> Hi Everyone, Please review: http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.01/ Disable test until hotspot and jdk changes meet together. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Tue Feb 28 03:58:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 11:58:13 +0000 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4CC092.7020007@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> <4F4CC092.7020007@oracle.com> Message-ID: <4F4CC155.3020506@oracle.com> On 28/02/2012 11:54, Dmitry Samersoff wrote: > Hi Everyone, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.01/ > > Disable test until hotspot and jdk changes meet together. > > -Dmitry > It would be best to add it to the jdk_management section (in the Makefile you'll see that the jdk_management target maps to a set of test directories that include sun/management/**). -Alan From staffan.larsen at oracle.com Tue Feb 28 04:00:02 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Feb 2012 13:00:02 +0100 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4CC092.7020007@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> <4F4CC092.7020007@oracle.com> Message-ID: <357D739F-FEA6-41A6-AADB-63B75A439E42@oracle.com> Looks good! On 28 feb 2012, at 12:54, Dmitry Samersoff wrote: > Hi Everyone, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.01/ > > Disable test until hotspot and jdk changes meet together. > > -Dmitry > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From karen.kinnear at oracle.com Tue Feb 28 04:10:09 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 28 Feb 2012 07:10:09 -0500 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4CC092.7020007@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> <4F4CC092.7020007@oracle.com> Message-ID: <8F25EFE9-D229-4C33-BE3A-C500DF571471@oracle.com> Looks good. Thanks Dmitry. Karen On Feb 28, 2012, at 6:54 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.01/ > > Disable test until hotspot and jdk changes meet together. > > -Dmitry > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Feb 28 05:02:11 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Feb 2012 17:02:11 +0400 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4CC155.3020506@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> <4F4CC092.7020007@oracle.com> <4F4CC155.3020506@oracle.com> Message-ID: <4F4CD053.3060201@oracle.com> Alan, done. http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.02/ -Dmitry On 2012-02-28 15:58, Alan Bateman wrote: > On 28/02/2012 11:54, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.01/ >> >> Disable test until hotspot and jdk changes meet together. >> >> -Dmitry >> > It would be best to add it to the jdk_management section (in the > Makefile you'll see that the jdk_management target maps to a set of test > directories that include sun/management/**). > > -Alan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Tue Feb 28 05:03:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 13:03:25 +0000 Subject: RR(XS) 7149181:sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms In-Reply-To: <4F4CD053.3060201@oracle.com> References: <4F4BC9A5.2010807@oracle.com> <4F4BDF28.2050507@oracle.com> <4F4BEC02.20902@oracle.com> <4F4CC092.7020007@oracle.com> <4F4CC155.3020506@oracle.com> <4F4CD053.3060201@oracle.com> Message-ID: <4F4CD09D.6090502@oracle.com> On 28/02/2012 13:02, Dmitry Samersoff wrote: > Alan, > > done. > > http://cr.openjdk.java.net/~dsamersoff/7149181/webrev.02/ > > -Dmitry > Looks fine to me. -Alan. From dmitriy.samersoff at oracle.com Tue Feb 28 05:04:12 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Tue, 28 Feb 2012 13:04:12 +0000 Subject: hg: jdk8/tl/jdk: 7149181: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms Message-ID: <20120228130438.7119F476E2@hg.openjdk.java.net> Changeset: c0a5140c641c Author: dsamersoff Date: 2012-02-28 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0a5140c641c 7149181: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms Summary: Disable test until JDK and hotspot changes meet each other. Reviewed-by: alanb, acorn ! test/ProblemList.txt From jonathan.gibbons at oracle.com Tue Feb 28 10:26:38 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:26:38 +0000 Subject: hg: jdk8/tl/langtools: 7144951: fix minor javadoc issues Message-ID: <20120228182643.4D8E7476E5@hg.openjdk.java.net> Changeset: c4d6a8884ed8 Author: jjg Date: 2012-02-28 10:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4d6a8884ed8 7144951: fix minor javadoc issues Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/tools/doclets/package.html From jonathan.gibbons at oracle.com Tue Feb 28 10:34:17 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:34:17 +0000 Subject: hg: jdk8/tl/langtools: 7093891: support multiple task listeners Message-ID: <20120228183419.3A7AF476E6@hg.openjdk.java.net> Changeset: 62e611704863 Author: jjg Date: 2012-02-28 10:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62e611704863 7093891: support multiple task listeners Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/source/util/JavacTask.java + src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/api/taskListeners/TestSimpleAddRemove.java ! test/tools/javac/processing/loader/testClose/TestClose.java From jonathan.gibbons at oracle.com Tue Feb 28 10:48:24 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Feb 2012 18:48:24 +0000 Subject: hg: jdk8/tl/langtools: 7147183: test/tools/javac/apt.sh can be removed from tl/langtools repository Message-ID: <20120228184826.F249C476E7@hg.openjdk.java.net> Changeset: 6b86f7274c0a Author: jjg Date: 2012-02-28 10:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b86f7274c0a 7147183: test/tools/javac/apt.sh can be removed from tl/langtools repository Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com - test/tools/javac/apt.sh From frederic.parain at oracle.com Tue Feb 28 12:17:49 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Tue, 28 Feb 2012 20:17:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 11 new changesets Message-ID: <20120228201816.A3152476EE@hg.openjdk.java.net> Changeset: d9b93445a67c Author: vladidan Date: 2012-02-15 20:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d9b93445a67c 7129401: PPC: runtime/7100935/TestShortArraycopy.java fails Summary: pass assembler switches for PPC Reviewed-by: dholmes ! make/linux/makefiles/ppc.make Changeset: d79f8393df2b Author: bpittore Date: 2012-02-22 14:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d79f8393df2b Merge Changeset: 701a83c86f28 Author: jiangli Date: 2012-02-21 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/701a83c86f28 7120481: storeStore barrier in constructor with final field Summary: Issue storestore barrier before constructor return if the constructor write final field. Reviewed-by: dholmes, jrose, roland, coleenp Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 398c5d0fb0ae Author: bpittore Date: 2012-02-23 21:10 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/398c5d0fb0ae Merge Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags Changeset: 0ed0960af27d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0ed0960af27d Added tag jdk8-b27 for changeset 3b24e7e01d20 ! .hgtags Changeset: 975c4105f1e2 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/975c4105f1e2 Merge Changeset: b183b0863611 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b183b0863611 Added tag hs24-b01 for changeset 975c4105f1e2 ! .hgtags Changeset: 694fd3171eb0 Author: amurillo Date: 2012-02-24 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/694fd3171eb0 7148664: new hotspot build - hs24-b02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 205573af962c Author: fparain Date: 2012-02-28 07:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/205573af962c Merge From joe.darcy at oracle.com Tue Feb 28 13:15:01 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 28 Feb 2012 21:15:01 +0000 Subject: hg: jdk8/tl/jdk: 7149626: (reflect) Improve javadoc of java.lang.reflect.Executable Message-ID: <20120228211510.AFF94476F3@hg.openjdk.java.net> Changeset: b62922b54170 Author: darcy Date: 2012-02-28 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b62922b54170 7149626: (reflect) Improve javadoc of java.lang.reflect.Executable Reviewed-by: mduigou ! src/share/classes/java/lang/reflect/Executable.java From lana.steuck at oracle.com Tue Feb 28 21:13:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:40 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20120229051340.B1D6147701@hg.openjdk.java.net> Changeset: 97bb465be99d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/97bb465be99d Added tag jdk8-b27 for changeset 1533dfab9903 ! .hgtags Changeset: 9760a2114f51 Author: asaha Date: 2012-02-14 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9760a2114f51 Merge Changeset: d47bf204f34d Author: asaha Date: 2012-02-17 14:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d47bf204f34d Merge Changeset: 6e2541d60f4e Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e2541d60f4e Merge Changeset: d74f01115fb8 Author: lana Date: 2012-02-28 17:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d74f01115fb8 Merge From lana.steuck at oracle.com Tue Feb 28 21:13:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:40 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20120229051347.DB93E47702@hg.openjdk.java.net> Changeset: 7bf4278af030 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7bf4278af030 Added tag jdk8-b27 for changeset 4fffe75e4edd ! .hgtags Changeset: 66c7161ee588 Author: coffeys Date: 2011-11-17 10:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/66c7161ee588 7110704: Issues with some method in corba Reviewed-by: mbankal ! src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java ! src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java Changeset: c4afff3939d8 Author: asaha Date: 2012-02-14 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/c4afff3939d8 Merge Changeset: 695408e22b29 Author: asaha Date: 2012-02-17 14:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/695408e22b29 Merge Changeset: 2082eb35d49a Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2082eb35d49a Merge From lana.steuck at oracle.com Tue Feb 28 21:13:49 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:49 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20120229051349.2F80247703@hg.openjdk.java.net> Changeset: 38cc4c09b847 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/38cc4c09b847 Added tag jdk8-b27 for changeset 80c47eb83d24 ! .hgtags Changeset: 6fc515ab48c3 Author: asaha Date: 2012-02-14 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6fc515ab48c3 Merge Changeset: a8e76ac83b62 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a8e76ac83b62 Merge Changeset: f3244c1f0486 Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f3244c1f0486 Merge From lana.steuck at oracle.com Tue Feb 28 21:13:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:51 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20120229051351.93C1947704@hg.openjdk.java.net> Changeset: 6a2e8a833460 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6a2e8a833460 Added tag jdk8-b27 for changeset 38c037af4127 ! .hgtags Changeset: 4289a81ba085 Author: asaha Date: 2012-02-14 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4289a81ba085 Merge Changeset: 456621c5d797 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/456621c5d797 Merge Changeset: c88e83be4b1a Author: lana Date: 2012-02-23 00:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c88e83be4b1a Merge Changeset: 88b85470e72c Author: lana Date: 2012-02-24 18:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88b85470e72c Merge From lana.steuck at oracle.com Tue Feb 28 21:13:44 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:44 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b27 for changeset 3b24e7e01d20 Message-ID: <20120229051351.D38E547705@hg.openjdk.java.net> Changeset: 0ed0960af27d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ed0960af27d Added tag jdk8-b27 for changeset 3b24e7e01d20 ! .hgtags From lana.steuck at oracle.com Tue Feb 28 21:13:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:13:56 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20120229051412.1140847706@hg.openjdk.java.net> Changeset: 8503479162bd Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8503479162bd Added tag jdk8-b27 for changeset be456f9c64e8 ! .hgtags Changeset: 3b168225dfc0 Author: asaha Date: 2012-02-14 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b168225dfc0 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: d903497bf389 Author: asaha Date: 2012-02-17 14:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d903497bf389 Merge Changeset: a696a8610b2a Author: lana Date: 2012-02-23 07:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a696a8610b2a Merge Changeset: 5bed623b0c77 Author: lana Date: 2012-02-24 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5bed623b0c77 Merge Changeset: 3d3350aea968 Author: lana Date: 2012-02-28 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d3350aea968 Merge From lana.steuck at oracle.com Tue Feb 28 21:14:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 29 Feb 2012 05:14:12 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20120229051711.E42E047707@hg.openjdk.java.net> Changeset: 7d683ab46571 Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d683ab46571 Added tag jdk8-b27 for changeset c68342532e2e ! .hgtags Changeset: 2152ac3e4575 Author: dl Date: 2011-10-12 16:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2152ac3e4575 7082299: AtomicReferenceArray should ensure that array is Object[] Reviewed-by: chegar, dholmes, alanb ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java Changeset: 23c3d1a0e150 Author: amenkov Date: 2011-10-26 14:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23c3d1a0e150 7088367: JavaSound security issue (12865443) Reviewed-by: denis ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java Changeset: 3ee041967af6 Author: smarks Date: 2011-11-11 15:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ee041967af6 7110700: Enhance exception throwing mechanism in ObjectStreamClass Reviewed-by: dmeetry, hawtin ! src/share/classes/java/io/ObjectStreamClass.java ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java Changeset: 18335c98ab8b Author: smarks Date: 2011-11-17 15:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18335c98ab8b 7112267: clean up fix for 7110700 Reviewed-by: dmeetry ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java Changeset: 4b98d2682c31 Author: okutsu Date: 2011-12-14 11:23 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b98d2682c31 6351654: Problem with java/classes_util_i18n Reviewed-by: hawtin, coffeys ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/awt/AppContext.java + src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 5d7e49a3a2f9 Author: bagiras Date: 2011-12-14 14:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d7e49a3a2f9 7112642: Incorrect checking for graphics rendering object Reviewed-by: art, bae ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java ! src/windows/classes/sun/java2d/windows/GDIRenderer.java ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp Changeset: a7cb0afadbee Author: sherman Date: 2011-12-15 14:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cb0afadbee 7118283: Better input parameter checking in zip file processing Summary: Fixed off-by-one bug in zip_util.c Reviewed-by: alanb ! src/share/native/java/util/zip/zip_util.c Changeset: d544965b59fe Author: bagiras Date: 2011-12-28 14:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d544965b59fe 7121482: some sun/java2d and sun/awt tests failed with InvalidPipeException since 1.7.0_03b02, 6u31b02 Reviewed-by: art, bae ! src/share/classes/sun/java2d/SunGraphics2D.java Changeset: 5e6f3c8646cf Author: xuelei Date: 2012-01-09 20:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e6f3c8646cf 7123519: problems with certification path Summary: Also including the contribution from Dennis Gu Reviewed-by: mullan, weijun ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + src/share/classes/sun/security/provider/certpath/UntrustedChecker.java + src/share/classes/sun/security/util/UntrustedCertificates.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/validator/ValidatorException.java + test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java + test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java + test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ComodoHacker.java Changeset: d9897e95323c Author: chegar Date: 2012-01-18 15:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9897e95323c 7126960: Add property to limit number of request headers to the HTTP Server Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerConfig.java Changeset: 7699f0a9c6d7 Author: asaha Date: 2012-02-20 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7699f0a9c6d7 Merge ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/validator/SimpleValidator.java Changeset: f525c1e9e12c Author: lana Date: 2012-02-23 00:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f525c1e9e12c Merge Changeset: fcdd5a4bae0e Author: lana Date: 2012-02-23 07:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcdd5a4bae0e Merge Changeset: ca2218135bac Author: asaha Date: 2012-02-24 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca2218135bac 7148758: Resolve merge issue which caused testcase failure Reviewed-by: alanb, chegar ! src/share/classes/sun/net/httpserver/ServerConfig.java Changeset: 39dcb3264fb3 Author: lana Date: 2012-02-24 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39dcb3264fb3 Merge Changeset: 1e1d41daaded Author: lana Date: 2012-02-24 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e1d41daaded Merge Changeset: 61c36875de46 Author: lana Date: 2012-02-28 18:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61c36875de46 Merge From kumar.x.srinivasan at oracle.com Wed Feb 29 08:21:53 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 29 Feb 2012 16:21:53 +0000 Subject: hg: jdk8/tl/jdk: 7148499: Stack size in tools/launcher/Settings.java needs to be increased Message-ID: <20120229162215.EAD964771C@hg.openjdk.java.net> Changeset: bd43a6f59c9b Author: ksrini Date: 2012-02-29 08:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd43a6f59c9b 7148499: Stack size in tools/launcher/Settings.java needs to be increased Reviewed-by: alanb ! test/ProblemList.txt ! test/tools/launcher/Settings.java From dbhole at redhat.com Wed Feb 29 12:30:06 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 29 Feb 2012 15:30:06 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F2756C9.4000304@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> Message-ID: <20120229203004.GA32730@redhat.com> * David Holmes [2012-01-30 21:50]: > On 31/01/2012 12:36 PM, Deepak Bhole wrote: > >* David Holmes [2012-01-30 19:57]: > >>While gcc compilation on sparc is rare I'm not sure that simply > >>deleting the sparc-only option unconditionally is the right thing to > >>do. > >> > > > >I thought about that too. But I was unable to find info on OpenJDK + > >SPARC + Linux. Is that combination even supported? The README doesn't > >list it: > >http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE > > Linux-sparc is not one of Oracle's supported OpenJDK platforms. > However AFAIK there are people in the community building OpenJDK on > Linux-sparc using the Zero interpreter. I don't know if this would > affect them but it still seems to me that we should be careful not > to break other people's builds. > With FOSDEM and subsequent security errata, this got pushed to side. Sorry for the delay. I've created a new webrev which contains a special case for the Sparc family (on Linux): http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ If it is okay for push, please go ahead and push it (I don't have commit access). I will then propose it for 7u. Thanks, Deepak > David > ----- > > >The option seemed more like a relic from Solaris + SPARC config rather > >than a requirement for Linux + SPARC. > > > > >Cheers, > >Deepak > > > >>David > >> > >>On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>>Hi, > >>> > >>>JDK builds currently fail with GCC 4.7 due to its stricter option > >>>checking. > >>> > >>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > >>>files in JDK supply the -mimpure-text option to GCC. This option is only > >>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > >>>on Linux (I suppose . > >>> > >>>This patch removes the option: > >>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>> > >>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>>2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>> > >>>If OK for push, please feel free to do so (I don't have commit access). > >>> > >>>Cheers, > >>>Deepak From david.holmes at oracle.com Wed Feb 29 15:28:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Mar 2012 09:28:26 +1000 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120229203004.GA32730@redhat.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> Message-ID: <4F4EB49A.8060909@oracle.com> Hi Deepak, On 1/03/2012 6:30 AM, Deepak Bhole wrote: > * David Holmes [2012-01-30 21:50]: >> On 31/01/2012 12:36 PM, Deepak Bhole wrote: >>> * David Holmes [2012-01-30 19:57]: >>>> While gcc compilation on sparc is rare I'm not sure that simply >>>> deleting the sparc-only option unconditionally is the right thing to >>>> do. >>>> >>> >>> I thought about that too. But I was unable to find info on OpenJDK + >>> SPARC + Linux. Is that combination even supported? The README doesn't >>> list it: >>> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE >> >> Linux-sparc is not one of Oracle's supported OpenJDK platforms. >> However AFAIK there are people in the community building OpenJDK on >> Linux-sparc using the Zero interpreter. I don't know if this would >> affect them but it still seems to me that we should be careful not >> to break other people's builds. >> > > With FOSDEM and subsequent security errata, this got pushed to side. > > Sorry for the delay. I've created a new webrev which contains a special > case for the Sparc family (on Linux): > > http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ Where is ARCH_FAMILY being set? David > If it is okay for push, please go ahead and push it (I don't have commit > access). I will then propose it for 7u. > > Thanks, > Deepak > >> David >> ----- >> >>> The option seemed more like a relic from Solaris + SPARC config rather >>> than a requirement for Linux + SPARC. >> >> >> >>> Cheers, >>> Deepak >>> >>>> David >>>> >>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>> Hi, >>>>> >>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>> checking. >>>>> >>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain >>>>> files in JDK supply the -mimpure-text option to GCC. This option is only >>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build >>>>> on Linux (I suppose . >>>>> >>>>> This patch removes the option: >>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>> >>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>> >>>>> If OK for push, please feel free to do so (I don't have commit access). >>>>> >>>>> Cheers, >>>>> Deepak From dbhole at redhat.com Wed Feb 29 15:43:18 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 29 Feb 2012 18:43:18 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F4EB49A.8060909@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> Message-ID: <20120229234318.GB32730@redhat.com> * David Holmes [2012-02-29 18:29]: > Hi Deepak, > > On 1/03/2012 6:30 AM, Deepak Bhole wrote: > >* David Holmes [2012-01-30 21:50]: > >>On 31/01/2012 12:36 PM, Deepak Bhole wrote: > >>>* David Holmes [2012-01-30 19:57]: > >>>>While gcc compilation on sparc is rare I'm not sure that simply > >>>>deleting the sparc-only option unconditionally is the right thing to > >>>>do. > >>>> > >>> > >>>I thought about that too. But I was unable to find info on OpenJDK + > >>>SPARC + Linux. Is that combination even supported? The README doesn't > >>>list it: > >>>http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE > >> > >>Linux-sparc is not one of Oracle's supported OpenJDK platforms. > >>However AFAIK there are people in the community building OpenJDK on > >>Linux-sparc using the Zero interpreter. I don't know if this would > >>affect them but it still seems to me that we should be careful not > >>to break other people's builds. > >> > > > >With FOSDEM and subsequent security errata, this got pushed to side. > > > >Sorry for the delay. I've created a new webrev which contains a special > >case for the Sparc family (on Linux): > > > >http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ > > Where is ARCH_FAMILY being set? > It is set in make/common/shared/Platform.gmk Deepak > David > > > >If it is okay for push, please go ahead and push it (I don't have commit > >access). I will then propose it for 7u. > > > >Thanks, > >Deepak > > > >>David > >>----- > >> > >>>The option seemed more like a relic from Solaris + SPARC config rather > >>>than a requirement for Linux + SPARC. > >> > >> > >> > >>>Cheers, > >>>Deepak > >>> > >>>>David > >>>> > >>>>On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>>>>Hi, > >>>>> > >>>>>JDK builds currently fail with GCC 4.7 due to its stricter option > >>>>>checking. > >>>>> > >>>>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > >>>>>files in JDK supply the -mimpure-text option to GCC. This option is only > >>>>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > >>>>>on Linux (I suppose . > >>>>> > >>>>>This patch removes the option: > >>>>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>>>> > >>>>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>>>>2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>>>> > >>>>>If OK for push, please feel free to do so (I don't have commit access). > >>>>> > >>>>>Cheers, > >>>>>Deepak From david.holmes at oracle.com Wed Feb 29 15:47:30 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Mar 2012 09:47:30 +1000 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F4EB49A.8060909@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> Message-ID: <4F4EB912.2070708@oracle.com> Sorry let me back up a step here. The issue with linux-sparc involved the actual build instructions in Compiler-gcc.gmk, not so much the sample makefiles for the various JVMTI demos - at least in my response. Unless someone from serviceability indicates otherwise I'd suggest just deleting -mimpure-text from those samples. Just to confuse things further, the gcc manual now lists this as a Solaris 2 option _not_ a sparc option: http://gcc.gnu.org/onlinedocs/gcc/Solaris-2-Options.html#index-mimpure_002dtext-2103 http://old.nabble.com/Correctly-document-Solaris-2-options-td29851048.html This seems to indicate the gcc folk are ignorant of linux-sparc! As we only used this option for linux builds and not Solaris builds I find this even more confusing. So at this point I will step back and let the build folk figure it out. David ----- On 1/03/2012 9:28 AM, David Holmes wrote: > Hi Deepak, > > On 1/03/2012 6:30 AM, Deepak Bhole wrote: >> * David Holmes [2012-01-30 21:50]: >>> On 31/01/2012 12:36 PM, Deepak Bhole wrote: >>>> * David Holmes [2012-01-30 19:57]: >>>>> While gcc compilation on sparc is rare I'm not sure that simply >>>>> deleting the sparc-only option unconditionally is the right thing to >>>>> do. >>>>> >>>> >>>> I thought about that too. But I was unable to find info on OpenJDK + >>>> SPARC + Linux. Is that combination even supported? The README doesn't >>>> list it: >>>> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE >>>> >>> >>> Linux-sparc is not one of Oracle's supported OpenJDK platforms. >>> However AFAIK there are people in the community building OpenJDK on >>> Linux-sparc using the Zero interpreter. I don't know if this would >>> affect them but it still seems to me that we should be careful not >>> to break other people's builds. >>> >> >> With FOSDEM and subsequent security errata, this got pushed to side. >> >> Sorry for the delay. I've created a new webrev which contains a special >> case for the Sparc family (on Linux): >> >> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ > > Where is ARCH_FAMILY being set? > > David > > >> If it is okay for push, please go ahead and push it (I don't have commit >> access). I will then propose it for 7u. >> >> Thanks, >> Deepak >> >>> David >>> ----- >>> >>>> The option seemed more like a relic from Solaris + SPARC config rather >>>> than a requirement for Linux + SPARC. >>> >>> >>> >>>> Cheers, >>>> Deepak >>>> >>>>> David >>>>> >>>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>>> Hi, >>>>>> >>>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>>> checking. >>>>>> >>>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. >>>>>> Certain >>>>>> files in JDK supply the -mimpure-text option to GCC. This option >>>>>> is only >>>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during >>>>>> build >>>>>> on Linux (I suppose . >>>>>> >>>>>> This patch removes the option: >>>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>>> >>>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>>> 2: >>>>>> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>>> >>>>>> >>>>>> If OK for push, please feel free to do so (I don't have commit >>>>>> access). >>>>>> >>>>>> Cheers, >>>>>> Deepak From david.holmes at oracle.com Wed Feb 29 15:48:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Mar 2012 09:48:25 +1000 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120229234318.GB32730@redhat.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> <20120229234318.GB32730@redhat.com> Message-ID: <4F4EB949.70303@oracle.com> On 1/03/2012 9:43 AM, Deepak Bhole wrote: > * David Holmes [2012-02-29 18:29]: >>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ >> >> Where is ARCH_FAMILY being set? >> > > It is set in make/common/shared/Platform.gmk But that has no connection to the sample Makefiles. David > Deepak > >> David >> >> >>> If it is okay for push, please go ahead and push it (I don't have commit >>> access). I will then propose it for 7u. >>> >>> Thanks, >>> Deepak >>> >>>> David >>>> ----- >>>> >>>>> The option seemed more like a relic from Solaris + SPARC config rather >>>>> than a requirement for Linux + SPARC. >>>> >>>> >>>> >>>>> Cheers, >>>>> Deepak >>>>> >>>>>> David >>>>>> >>>>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>>>> Hi, >>>>>>> >>>>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>>>> checking. >>>>>>> >>>>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain >>>>>>> files in JDK supply the -mimpure-text option to GCC. This option is only >>>>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build >>>>>>> on Linux (I suppose . >>>>>>> >>>>>>> This patch removes the option: >>>>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>>>> >>>>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>>>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>>>> >>>>>>> If OK for push, please feel free to do so (I don't have commit access). >>>>>>> >>>>>>> Cheers, >>>>>>> Deepak From dbhole at redhat.com Wed Feb 29 16:03:06 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 29 Feb 2012 19:03:06 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F4EB949.70303@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> <20120229234318.GB32730@redhat.com> <4F4EB949.70303@oracle.com> Message-ID: <20120301000306.GC32730@redhat.com> * David Holmes [2012-02-29 18:49]: > On 1/03/2012 9:43 AM, Deepak Bhole wrote: > >* David Holmes [2012-02-29 18:29]: > >>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ > >> > >>Where is ARCH_FAMILY being set? > >> > > > >It is set in make/common/shared/Platform.gmk > > But that has no connection to the sample Makefiles. > Ah ok. Sorry, I haven't done much work with the build system before. Didn't realize that demo make files were run standalone. In that case, a LIBARCH and OSNAME check there should suffice as the surrounding code uses those. Deepak > David > > >Deepak > > > >>David > >> > >> > >>>If it is okay for push, please go ahead and push it (I don't have commit > >>>access). I will then propose it for 7u. > >>> > >>>Thanks, > >>>Deepak > >>> > >>>>David > >>>>----- > >>>> > >>>>>The option seemed more like a relic from Solaris + SPARC config rather > >>>>>than a requirement for Linux + SPARC. > >>>> > >>>> > >>>> > >>>>>Cheers, > >>>>>Deepak > >>>>> > >>>>>>David > >>>>>> > >>>>>>On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>>>>>>Hi, > >>>>>>> > >>>>>>>JDK builds currently fail with GCC 4.7 due to its stricter option > >>>>>>>checking. > >>>>>>> > >>>>>>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > >>>>>>>files in JDK supply the -mimpure-text option to GCC. This option is only > >>>>>>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > >>>>>>>on Linux (I suppose . > >>>>>>> > >>>>>>>This patch removes the option: > >>>>>>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>>>>>> > >>>>>>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>>>>>>2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>>>>>> > >>>>>>>If OK for push, please feel free to do so (I don't have commit access). > >>>>>>> > >>>>>>>Cheers, > >>>>>>>Deepak From dbhole at redhat.com Wed Feb 29 16:04:58 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 29 Feb 2012 19:04:58 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F4EB912.2070708@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> <4F4EB912.2070708@oracle.com> Message-ID: <20120301000457.GD32730@redhat.com> * David Holmes [2012-02-29 18:48]: > Sorry let me back up a step here. The issue with linux-sparc > involved the actual build instructions in Compiler-gcc.gmk, not so > much the sample makefiles for the various JVMTI demos - at least in > my response. Unless someone from serviceability indicates otherwise > I'd suggest just deleting -mimpure-text from those samples. > > Just to confuse things further, the gcc manual now lists this as a > Solaris 2 option _not_ a sparc option: > > http://gcc.gnu.org/onlinedocs/gcc/Solaris-2-Options.html#index-mimpure_002dtext-2103 > > http://old.nabble.com/Correctly-document-Solaris-2-options-td29851048.html > > This seems to indicate the gcc folk are ignorant of linux-sparc! > Gah :/ > As we only used this option for linux builds and not Solaris builds > I find this even more confusing. > > So at this point I will step back and let the build folk figure it out. > Removing it might probably be correct then, since it is not applicable to Linux. I will wait for someone with more experience to chime in though. Cheers, Deepak > David > ----- > > On 1/03/2012 9:28 AM, David Holmes wrote: > >Hi Deepak, > > > >On 1/03/2012 6:30 AM, Deepak Bhole wrote: > >>* David Holmes [2012-01-30 21:50]: > >>>On 31/01/2012 12:36 PM, Deepak Bhole wrote: > >>>>* David Holmes [2012-01-30 19:57]: > >>>>>While gcc compilation on sparc is rare I'm not sure that simply > >>>>>deleting the sparc-only option unconditionally is the right thing to > >>>>>do. > >>>>> > >>>> > >>>>I thought about that too. But I was unable to find info on OpenJDK + > >>>>SPARC + Linux. Is that combination even supported? The README doesn't > >>>>list it: > >>>>http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE > >>>> > >>> > >>>Linux-sparc is not one of Oracle's supported OpenJDK platforms. > >>>However AFAIK there are people in the community building OpenJDK on > >>>Linux-sparc using the Zero interpreter. I don't know if this would > >>>affect them but it still seems to me that we should be careful not > >>>to break other people's builds. > >>> > >> > >>With FOSDEM and subsequent security errata, this got pushed to side. > >> > >>Sorry for the delay. I've created a new webrev which contains a special > >>case for the Sparc family (on Linux): > >> > >>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ > > > >Where is ARCH_FAMILY being set? > > > >David > > > > > >>If it is okay for push, please go ahead and push it (I don't have commit > >>access). I will then propose it for 7u. > >> > >>Thanks, > >>Deepak > >> > >>>David > >>>----- > >>> > >>>>The option seemed more like a relic from Solaris + SPARC config rather > >>>>than a requirement for Linux + SPARC. > >>> > >>> > >>> > >>>>Cheers, > >>>>Deepak > >>>> > >>>>>David > >>>>> > >>>>>On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>>>>>Hi, > >>>>>> > >>>>>>JDK builds currently fail with GCC 4.7 due to its stricter option > >>>>>>checking. > >>>>>> > >>>>>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. > >>>>>>Certain > >>>>>>files in JDK supply the -mimpure-text option to GCC. This option > >>>>>>is only > >>>>>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during > >>>>>>build > >>>>>>on Linux (I suppose . > >>>>>> > >>>>>>This patch removes the option: > >>>>>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>>>>> > >>>>>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>>>>>2: > >>>>>>http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>>>>> > >>>>>> > >>>>>>If OK for push, please feel free to do so (I don't have commit > >>>>>>access). > >>>>>> > >>>>>>Cheers, > >>>>>>Deepak From kelly.ohair at oracle.com Wed Feb 29 17:39:24 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 29 Feb 2012 17:39:24 -0800 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120301000457.GD32730@redhat.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> <20120229203004.GA32730@redhat.com> <4F4EB49A.8060909@oracle.com> <4F4EB912.2070708@oracle.com> <20120301000457.GD32730@redhat.com> Message-ID: The sample.makefile.txt files may not even be used during the build, I'm not sure. They may have only been supplied as documentation on how to build the native code. Deleting the -mimpure-text is probably right all around. -kto On Feb 29, 2012, at 4:04 PM, Deepak Bhole wrote: > * David Holmes [2012-02-29 18:48]: >> Sorry let me back up a step here. The issue with linux-sparc >> involved the actual build instructions in Compiler-gcc.gmk, not so >> much the sample makefiles for the various JVMTI demos - at least in >> my response. Unless someone from serviceability indicates otherwise >> I'd suggest just deleting -mimpure-text from those samples. >> >> Just to confuse things further, the gcc manual now lists this as a >> Solaris 2 option _not_ a sparc option: >> >> http://gcc.gnu.org/onlinedocs/gcc/Solaris-2-Options.html#index-mimpure_002dtext-2103 >> >> http://old.nabble.com/Correctly-document-Solaris-2-options-td29851048.html >> >> This seems to indicate the gcc folk are ignorant of linux-sparc! >> > > Gah :/ > >> As we only used this option for linux builds and not Solaris builds >> I find this even more confusing. >> >> So at this point I will step back and let the build folk figure it out. >> > > Removing it might probably be correct then, since it is not applicable > to Linux. I will wait for someone with more experience to chime in > though. > > Cheers, > Deepak > >> David >> ----- >> >> On 1/03/2012 9:28 AM, David Holmes wrote: >>> Hi Deepak, >>> >>> On 1/03/2012 6:30 AM, Deepak Bhole wrote: >>>> * David Holmes [2012-01-30 21:50]: >>>>> On 31/01/2012 12:36 PM, Deepak Bhole wrote: >>>>>> * David Holmes [2012-01-30 19:57]: >>>>>>> While gcc compilation on sparc is rare I'm not sure that simply >>>>>>> deleting the sparc-only option unconditionally is the right thing to >>>>>>> do. >>>>>>> >>>>>> >>>>>> I thought about that too. But I was unable to find info on OpenJDK + >>>>>> SPARC + Linux. Is that combination even supported? The README doesn't >>>>>> list it: >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE >>>>>> >>>>> >>>>> Linux-sparc is not one of Oracle's supported OpenJDK platforms. >>>>> However AFAIK there are people in the community building OpenJDK on >>>>> Linux-sparc using the Zero interpreter. I don't know if this would >>>>> affect them but it still seems to me that we should be careful not >>>>> to break other people's builds. >>>>> >>>> >>>> With FOSDEM and subsequent security errata, this got pushed to side. >>>> >>>> Sorry for the delay. I've created a new webrev which contains a special >>>> case for the Sparc family (on Linux): >>>> >>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.01/ >>> >>> Where is ARCH_FAMILY being set? >>> >>> David >>> >>> >>>> If it is okay for push, please go ahead and push it (I don't have commit >>>> access). I will then propose it for 7u. >>>> >>>> Thanks, >>>> Deepak >>>> >>>>> David >>>>> ----- >>>>> >>>>>> The option seemed more like a relic from Solaris + SPARC config rather >>>>>> than a requirement for Linux + SPARC. >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> Deepak >>>>>> >>>>>>> David >>>>>>> >>>>>>> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> JDK builds currently fail with GCC 4.7 due to its stricter option >>>>>>>> checking. >>>>>>>> >>>>>>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. >>>>>>>> Certain >>>>>>>> files in JDK supply the -mimpure-text option to GCC. This option >>>>>>>> is only >>>>>>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during >>>>>>>> build >>>>>>>> on Linux (I suppose . >>>>>>>> >>>>>>>> This patch removes the option: >>>>>>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>>>>>>> >>>>>>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>>>>>>> 2: >>>>>>>> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>>>>>>> >>>>>>>> >>>>>>>> If OK for push, please feel free to do so (I don't have commit >>>>>>>> access). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Deepak From suenaga.yasumasa at oss.ntt.co.jp Wed Feb 29 22:41:58 2012 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 01 Mar 2012 15:41:58 +0900 Subject: 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Message-ID: <4F4F1A36.4000702@oss.ntt.co.jp> Hi, About a month ago, I submitted a patch to fix this CR. How is the status of this CR? http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-January/005174.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-January/005175.html If java system is crashed, I want to get Java-level stack trace from core image to understand detail of troubles. So I would like to contribute this patch. Thanks, Yasumasa