From staffan.larsen at oracle.com Fri Mar 1 00:31:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 1 Mar 2013 09:31:07 +0100 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <51305FE0.8080701@oracle.com> References: <512FE73E.2020709@oracle.com> <51305177.7070302@oracle.com> <4BF5E080-8896-4090-A30B-EEA4494031C3@oracle.com> <51305FE0.8080701@oracle.com> Message-ID: On 1 mar 2013, at 08:59, David Holmes wrote: > On 1/03/2013 5:37 PM, Staffan Larsen wrote: >> >> On 1 mar 2013, at 07:57, David Holmes wrote: >> >>> Hi Calvin, >>> >>> So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? >> >> It does add the code that creates the event and pushes it into the event tracing framework. This is all that is required to add a new event to the event tracing. > > Now that was weird. When I loaded the webrev the systemDictionary.cpp change stopped just after the post_class_load_event method. I didn't see the changes that used the post_class_load_event method. Aha! > So now that I can see them ... the event is being recorded prematurely: > > 816 // If everything was OK (no exceptions, no null return value), > 817 // post a class load event. > 818 if (!HAS_PENDING_EXCEPTION && !k.is_null()) { > 819 // post class load event > 820 post_class_load_event(starttime, k, class_loader); > 821 > 822 // class_loader is NOT the defining loader, do a little more bookkeeping. > 823 if (k->class_loader() != class_loader()) { > > 824 > 825 check_constraints(d_index, d_hash, k, class_loader, false, THREAD); > 826 > 827 // Need to check for a PENDING_EXCEPTION again; check_constraints > 828 // can throw and doesn't use the CHECK macro. > > The class isn't really loaded until it has passed the loader constraint check. And later the protection domain validation check could fail. I brought this up earlier as well and the answer had to do with the event reporting both the initiating and the defining class loader (as opposed to the JVMTI event which only reports the defining class loader). > >>> Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. >> >> You can store raw oops into the event. We take care to make sure they are never referenced after the commit() is called. > > Sorry I misread the code. You don't store the loader oop you store the klass() - so this just records the type of the Loader rather than identifying the actual instance. What do you do with these values - just treat them as addresses that you print? (Same question if you store oops - what can you do with an oop you can't reference?) When the event is printed (further down in the commit() chain) the names of the classes will be included. /Staffan > > David > >> /Staffan >> >>> >>> David >>> >>> On 1/03/2013 9:24 AM, Calvin Cheung wrote: >>>> This change is for adding the class load event tracing. >>>> The event will include the following fields: >>>> loaded class >>>> defining class loader >>>> initiating class loader >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ >>>> >>>> thanks, >>>> Calvin >> From david.holmes at oracle.com Fri Mar 1 00:45:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 18:45:38 +1000 Subject: Review request: 8009174: add class load event tracing In-Reply-To: References: <512FE73E.2020709@oracle.com> <51305177.7070302@oracle.com> <4BF5E080-8896-4090-A30B-EEA4494031C3@oracle.com> <51305FE0.8080701@oracle.com> Message-ID: <51306AB2.8040805@oracle.com> On 1/03/2013 6:31 PM, Staffan Larsen wrote: > > On 1 mar 2013, at 08:59, David Holmes wrote: > >> On 1/03/2013 5:37 PM, Staffan Larsen wrote: >>> >>> On 1 mar 2013, at 07:57, David Holmes wrote: >>> >>>> Hi Calvin, >>>> >>>> So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? >>> >>> It does add the code that creates the event and pushes it into the event tracing framework. This is all that is required to add a new event to the event tracing. >> >> Now that was weird. When I loaded the webrev the systemDictionary.cpp change stopped just after the post_class_load_event method. I didn't see the changes that used the post_class_load_event method. > > Aha! > >> So now that I can see them ... the event is being recorded prematurely: >> >> 816 // If everything was OK (no exceptions, no null return value), >> 817 // post a class load event. >> 818 if (!HAS_PENDING_EXCEPTION && !k.is_null()) { >> 819 // post class load event >> 820 post_class_load_event(starttime, k, class_loader); >> 821 >> 822 // class_loader is NOT the defining loader, do a little more bookkeeping. >> 823 if (k->class_loader() != class_loader()) { >> >> 824 >> 825 check_constraints(d_index, d_hash, k, class_loader, false, THREAD); >> 826 >> 827 // Need to check for a PENDING_EXCEPTION again; check_constraints >> 828 // can throw and doesn't use the CHECK macro. >> >> The class isn't really loaded until it has passed the loader constraint check. And later the protection domain validation check could fail. > > I brought this up earlier as well and the answer had to do with the event reporting both the initiating and the defining class loader (as opposed to the JVMTI event which only reports the defining class loader). So this is really a "class load attempted" event? But I don't understand your comment as the same information is available after the loader constraint check etc. >> >>>> Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. >>> >>> You can store raw oops into the event. We take care to make sure they are never referenced after the commit() is called. >> >> Sorry I misread the code. You don't store the loader oop you store the klass() - so this just records the type of the Loader rather than identifying the actual instance. What do you do with these values - just treat them as addresses that you print? (Same question if you store oops - what can you do with an oop you can't reference?) > > When the event is printed (further down in the commit() chain) the names of the classes will be included. How do you get the name of the class from a value that might not be valid at the time you want to extract the name? Is this info already stored elsewhere, indexed by the value you stored? Thanks, David > /Staffan > >> >> David >> >>> /Staffan >>> >>>> >>>> David >>>> >>>> On 1/03/2013 9:24 AM, Calvin Cheung wrote: >>>>> This change is for adding the class load event tracing. >>>>> The event will include the following fields: >>>>> loaded class >>>>> defining class loader >>>>> initiating class loader >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ >>>>> >>>>> thanks, >>>>> Calvin >>> > From john.cuthbertson at oracle.com Fri Mar 1 04:02:27 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 01 Mar 2013 12:02:27 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130301120237.18F6B47514@hg.openjdk.java.net> Changeset: a4debcca0fb9 Author: johnc Date: 2013-02-04 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a4debcca0fb9 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero Summary: Flush any deferred card mark before a Java thread exits. Reviewed-by: brutisso, jmasa ! src/share/vm/runtime/thread.cpp Changeset: f33d68f8b40e Author: johnc Date: 2013-02-28 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f33d68f8b40e Merge From joseph.provino at oracle.com Fri Mar 1 06:31:38 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Fri, 01 Mar 2013 09:31:38 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <51304BE9.9080206@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> <51304BE9.9080206@oracle.com> Message-ID: <5130BBCA.2060803@oracle.com> On 3/1/2013 1:34 AM, David Holmes wrote: > On 1/03/2013 4:54 AM, JOSEPH PROVINO wrote: >> Latest webrev is here: >> http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 > > One lingering glitch: > > 3273 if (DumpSharedSpaces || RequireSharedSpaces) { > 3274 jio_fprintf(defaultStream::error_stream(), > 3275 "Shared spaces are not supported in this VM\n"); > 3276 return JNI_ERR; > 3277 } > 3278 if (UseSharedSpaces || PrintSharedSpaces) { > 3279 warning("Shared spaces are not supported in this VM"); > 3280 } > 3281 FLAG_SET_DEFAULT(DumpSharedSpaces, false); > 3282 FLAG_SET_DEFAULT(RequireSharedSpaces, false); > 3283 FLAG_SET_DEFAULT(PrintSharedSpaces, false); > > The last three lines only need to be these two lines: > > FLAG_SET_DEFAULT(UseSharedSpaces, false); > FLAG_SET_DEFAULT(PrintSharedSpaces, false); > > and they can move inside the if. Okay, I'll make those changes. joe > > DumpSharedSpaces and RequireSharedSpaces must already be false else we > exit at #3276. > > David > ----- > >> joe >> >> On 2/27/2013 11:36 PM, David Holmes wrote: >>> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>>> >>>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>>> >>>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>>> Latest webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>>> >>>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>>> >>>>>>>> - confined changes for CDS to filemap.hpp. >>>>>>> >>>>>>> These changes are good - thanks. >>>>>>> >>>>>>> For arguments.cpp: >>>>>>> >>>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>>> >>>>>>> If we execute this line then the flag is already false. >>>>>>> >>>>>>> Also, as discussed in email -Xshare:dump should probably be an >>>>>>> error >>>>>>> not a warning, but note that if left as a warning then this code: >>>>>>> >>>>>>> 2518 // -Xshare:dump >>>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>>> creates objects >>>>>>> >>>>>>> would also force us into intepreter mode, so you would still >>>>>>> need to >>>>>>> check INCLUDE_CDS here. >>>>>> >>>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>>> conditional here? >>>>> >>>>> ?? You would need the conditional to decide to return JNI_ERR. >>>> >>>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >>> >>> So I was assuming this was the only place you needed to check this, >>> but you have to check for -XX:+DumpSharedSpaces as well. So if you >>> left the -Xshare:dump code alone and later checked for >>> DumpSharedSpaces and returned with JNI_ERR then it would not matter >>> that the switch to interpreter mode had already been made. >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> David >>>>> >>>>>> joe >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> joe >>>>>>>> >>>>>>>> >>>>>> >>>> >> From adomurad at redhat.com Fri Mar 1 06:48:09 2013 From: adomurad at redhat.com (Adam Domurad) Date: Fri, 1 Mar 2013 14:48:09 +0000 (UTC) Subject: Very poor performance of JNI AttachCurrentThread on Linux References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> Message-ID: Dmitry Samersoff writes: > > Andrew, > > Filed a bug JDK-8009062 > > -Dmitry > > On 2013-02-26 21:58, Andrew Haley wrote: > > get_stack_bounds() was rewritten because of a small memory leak. > > Instead of simply free()ing the memory to prevent the leak, it was > > rewritten to use a byte-by-byte loop around read() : > > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html [.. snipped ..] Hi, Dmitry. Thanks for filing the bug. I'd like to know if something like this would be suitable ? - Have a buffer for reading in the content (whether it be dynamically allocated once or fixed-size) - Read in as much as possible with read() - Scan the buffer contents for '[stack]' - If not found, go to the start of the line at the end of our buffer, and copy this line into the start of our buffer, repeat reading into the buffer after the point the copy - If found, the complete line should be in our buffer, so go to the start of the line from where we scanned and grab the stack bounds. This should get a chance to match '[stack]' on every line. Let me know if you'd like it in code. Happy hacking, -Adam From joseph.provino at oracle.com Fri Mar 1 06:53:13 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Fri, 01 Mar 2013 09:53:13 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <51300DD9.8060703@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> <512BAE75.5080800@oracle.com> <51300AE9.6080402@oracle.com> <51300DD9.8060703@oracle.com> Message-ID: <5130C0D9.9010803@oracle.com> On 2/28/2013 9:09 PM, Mikael Vidstedt wrote: > > Looks good! > > Do you think it'd make sense to move "-Wpointer-arith -Wsign-compare > -Wundef" out of the ifneq for {bsd,linux}/Makefile/gcc.make and only > leave the -Wconversion in there? yes, that makes sense. > I can do that as part of the pending -Wunused changes if you don't > want to update it now. That would be great. Since I have two reviews, I'd just as soon push now. thanks. joe > > Cheers, > Mikael > > On 2013-02-28 17:56, JOSEPH PROVINO wrote: >> Latest webrev is here: >> http://cr.openjdk.java.net/~jprovino/8006498/webrev.01 >> >> joe >> >> >> On 2/25/2013 1:33 PM, Mikael Vidstedt wrote: >>> >>> On 2/24/2013 2:59 PM, David Holmes wrote: >>>> On 23/02/2013 12:35 AM, Joseph Provino wrote: >>>>> On 02/21/2013 10:13 PM, David Holmes wrote: >>>>>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>>>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>>>>> Actually, from looking at this again, I thought David was >>>>>>>> suggesting >>>>>>>> that -Wundef >>>>>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>>>>> >>>>>>> I was being ambivalent - I just wanted to see consistency. We >>>>>>> should see >>>>>>> where Mikael is adding -Wunused >>>>>> >>>>>> Ha! Now this really muddies the waters (this is linux only): >>>>>> >>>>>> ! ADDITIONAL_WARNINGS = -Wunused-function >>>>>> ! >>>>>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>> $(ACCEPTABLE_WARNINGS) >>>>>> $(ADDITIONAL_WARNINGS) >>>>> >>>>> That's the problem -- it's already inconsistent. >>>> >>>> The names do not make sense to me but perhaps I am misunderstanding >>>> how this works. Are we listing all the warnings that will be >>>> errors, or are we listing those warnings that we don't want to be >>>> errors? I'm not understanding what acceptable nor additional are >>>> supposed to mean here. >>> >>> I can't say that I see any real patterns in how these variables are >>> used either. My guess is that at some point somebody figured out a >>> few warnings that were "acceptable" - as in warnings that we could >>> turn on without getting tons of false positives and incorrectly >>> generated code, but that's just a guess. Unless somebody has >>> insights around why these are named and split up the way they are I >>> suggest that we simplify and unify all of it. >>> >>> My suggestion is to have all the warning flags go into a variable >>> called WARNING_FLAGS, leaving only two variables: >>> WARNINGS_ARE_ERRORS and WARNING_FLAGS. Something like this (for >>> Linux, similar for Solaris): >>> >>> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions >>> -Wundef >>> >>> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >>> implicit >>> # conversions which might affect the values. To avoid that, we do >>> not use it. >>> ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >>> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >>> WARNING_FLAGS += -Wconversion >>> endif >>> >>> CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) >>> >>> Reasonable? >>> >>> Cheers, >>> Mikael >>> >>> >>>> >>>> David >>>> >>>>> joe >>>>> >>>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> joe >>>>>>>> >>>>>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>>>>> Solaris >>>>>>>>> if there is not particular reason not to. >>>>>>>>> >>>>>>>>> Other than that, look good to me. >>>>>>>>> >>>>>>>>> -Zhengyu >>>>>>>>> >>>>>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if >>>>>>>>>>> are >>>>>>>>>>> supposed to be defined or not >>>>>>>>>>> >>>>>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>>>>> references >>>>>>>>>>> to undefined macros. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Webrev is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>>>>> >>>>>>>>>> On bsd and linux you simply added -Wundef directly to the >>>>>>>>>> CFLAGS: >>>>>>>>>> >>>>>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>>>>> -Wundef >>>>>>>>>> >>>>>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>>>>> >>>>>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion >>>>>>>>>> -Wsign-compare >>>>>>>>>> -Wundef >>>>>>>>>> >>>>>>>>>> I guess it is a little confusing as to whether >>>>>>>>>> ACCEPTABLE_WARNINGS >>>>>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>>>>> >>>>>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> joe >>>>>>>>> >>>>>>>> >>>>> >>> >> > From karen.kinnear at oracle.com Fri Mar 1 06:53:33 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 1 Mar 2013 09:53:33 -0500 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <512FE73E.2020709@oracle.com> References: <512FE73E.2020709@oracle.com> Message-ID: <5F9CC3A7-0FE1-4138-813E-80BB972B5B09@oracle.com> Calvin, Looks good. Thanks for getting both the defining and initiating loaders. Karen On Feb 28, 2013, at 6:24 PM, Calvin Cheung wrote: > This change is for adding the class load event tracing. > The event will include the following fields: > loaded class > defining class loader > initiating class loader > > webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ > > thanks, > Calvin From dmitry.samersoff at oracle.com Fri Mar 1 08:00:43 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 01 Mar 2013 20:00:43 +0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> Message-ID: <5130D0AB.8000001@oracle.com> Adam, Thank you for advice! I'm looking for a possibility to remove get_stack_bounds function entirely as Dean suggested. But it takes some time. -Dmitry On 2013-03-01 18:48, Adam Domurad wrote: > Dmitry Samersoff writes: > >> >> Andrew, >> >> Filed a bug JDK-8009062 >> >> -Dmitry >> >> On 2013-02-26 21:58, Andrew Haley wrote: >>> get_stack_bounds() was rewritten because of a small memory leak. >>> Instead of simply free()ing the memory to prevent the leak, it was >>> rewritten to use a byte-by-byte loop around read() : >>> >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html > [.. snipped ..] > > Hi, Dmitry. > > Thanks for filing the bug. I'd like to know if something like this would be > suitable ? > > - Have a buffer for reading in the content (whether it be dynamically allocated > once or fixed-size) > - Read in as much as possible with read() > - Scan the buffer contents for '[stack]' > - If not found, go to the start of the line at the end of our buffer, and > copy this line into the start of our buffer, repeat reading into the buffer > after the point the copy > - If found, the complete line should be in our buffer, so go to the start of > the line from where we scanned and grab the stack bounds. > > This should get a chance to match '[stack]' on every line. > > Let me know if you'd like it in code. > > Happy hacking, > -Adam > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From alejandro.murillo at oracle.com Fri Mar 1 08:28:41 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Mar 2013 16:28:41 +0000 Subject: hg: hsx/hsx25/hotspot: 28 new changesets Message-ID: <20130301162947.6515C47518@hg.openjdk.java.net> Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags Changeset: be1fbee20765 Author: amurillo Date: 2013-02-22 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/be1fbee20765 8008692: new hotspot build - hs25-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b0dc9f87e75 Author: mgerdin Date: 2013-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b0dc9f87e75 8006753: fix failed for JDK-8002415 White box testing API for HotSpot Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make - make/bsd/makefiles/wb.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make - make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make - make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/runtime/NMT/AllocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/SummarySanityCheck.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java + test/testlibrary/ClassFileInstaller.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4c1d8002ffb1 Author: hseigel Date: 2013-02-20 07:16 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c1d8002ffb1 8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp Summary: Delete the questionable source code because it is for no-longer supported versions of Linux. Reviewed-by: mikael, coleenp ! src/os/linux/vm/os_linux.cpp Changeset: b861c8af2510 Author: hseigel Date: 2013-02-20 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b861c8af2510 Merge - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b6d5b3e50379 Author: dcubed Date: 2013-02-20 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b6d5b3e50379 6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors. Reviewed-by: dcubed, dholmes, coleenp, acorn Contributed-by: ron.durbin at oracle.com ! src/share/vm/utilities/debug.cpp Changeset: fc64254f5579 Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fc64254f5579 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp Changeset: 5ed317b25e23 Author: sla Date: 2013-02-22 10:03 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ed317b25e23 7165259: Remove BugSpot Reviewed-by: coleenp, mgronlun ! agent/make/Makefile - agent/make/bugspot.bat ! agent/make/marks_notes.html ! agent/src/os/win32/windbg/sawindbg.cpp - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp ! make/sa.files Changeset: f16e75e0cf11 Author: coleenp Date: 2013-02-22 08:36 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f16e75e0cf11 8000797: NPG: is_pseudo_string_at() doesn't work Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings). Clean up JVM_CONSTANT_Object and unused flags. Reviewed-by: sspitsyn, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 94478a033036 Author: sspitsyn Date: 2013-02-22 10:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94478a033036 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp Changeset: ec2eddfed950 Author: rbackman Date: 2013-02-26 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec2eddfed950 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 77f9b6d0126e Author: sspitsyn Date: 2013-02-27 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/77f9b6d0126e Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 0598674c0056 Author: jwilhelm Date: 2013-02-21 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0598674c0056 8008314: Unimplemented() Atomic::load breaks the applications Summary: jlong atomics isn't fully implemented om all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 96c885895d22 Author: johnc Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/96c885895d22 8007221: G1: concurrent phase durations do not state the time units ("secs") Summary: Add timer units to concurrent marking phases where the units were missing. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 9a8ee5301f33 Author: brutisso Date: 2013-02-26 11:52 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9a8ee5301f33 Merge Changeset: 9289a00709b5 Author: poonam Date: 2013-02-26 08:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9289a00709b5 Merge Changeset: b685ca4f4fb9 Author: ehelin Date: 2013-02-20 16:41 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b685ca4f4fb9 8008536: Add HotSpot support for printing class loader statistics for JMap Reviewed-by: sla, brutisso + agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 3d3379aab292 Author: ehelin Date: 2013-02-26 22:31 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3d3379aab292 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 9a094d29af19 Author: ehelin Date: 2013-02-06 07:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9a094d29af19 8004924: NPG: jmap -heap output should contain ClassMetaspaceSize value Reviewed-by: stefank, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java + test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: b5e03c8ead49 Author: brutisso Date: 2013-02-28 09:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5e03c8ead49 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 6931f425c517 Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6931f425c517 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 706c919d3b56 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/706c919d3b56 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: a00ed9736260 Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a00ed9736260 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 133bf557ef77 Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/133bf557ef77 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: b02157cd249f Author: vlivanov Date: 2013-02-27 08:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b02157cd249f Merge Changeset: 338da89b2592 Author: vlivanov Date: 2013-02-28 15:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/338da89b2592 Merge Changeset: df5396524152 Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df5396524152 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4a198b201f3c Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a198b201f3c Added tag hs25-b21 for changeset df5396524152 ! .hgtags From John.Coomes at oracle.com Fri Mar 1 12:57:09 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 1 Mar 2013 12:57:09 -0800 Subject: CFV: New HSX Committer: Markus =?iso-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <20785.5669.218536.170396@oracle.com> Vote: yes -John From alejandro.murillo at oracle.com Fri Mar 1 13:13:50 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Mar 2013 21:13:50 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130301211400.D3BB4477C1@hg.openjdk.java.net> Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags Changeset: df5396524152 Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df5396524152 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4a198b201f3c Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a198b201f3c Added tag hs25-b21 for changeset df5396524152 ! .hgtags Changeset: 7f482030ff64 Author: amurillo Date: 2013-03-01 04:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f482030ff64 8009226: new hotspot build - hs25-b22 Reviewed-by: jcoomes ! make/hotspot_version From daniel.daugherty at oracle.com Fri Mar 1 13:27:42 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 01 Mar 2013 21:27:42 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130301212750.4BCEF477C4@hg.openjdk.java.net> Changeset: 94227c0c6cf0 Author: dcubed Date: 2013-03-01 09:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/94227c0c6cf0 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 586fe6358916 Author: dcubed Date: 2013-03-01 09:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/586fe6358916 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 0930637d6520 Author: dcubed Date: 2013-03-01 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0930637d6520 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp From jiangli.zhou at oracle.com Fri Mar 1 13:44:50 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Fri, 01 Mar 2013 21:44:50 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130301214456.7411B477C6@hg.openjdk.java.net> Changeset: ce0cee0f0e00 Author: bpittore Date: 2013-02-28 12:09 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce0cee0f0e00 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: 69ff881ab627 Author: jiangli Date: 2013-03-01 04:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/69ff881ab627 Merge Changeset: 18c8cdc40cdf Author: jiangli Date: 2013-03-01 13:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/18c8cdc40cdf Merge From joseph.provino at oracle.com Mon Mar 4 07:11:45 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 04 Mar 2013 10:11:45 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <5130BBCA.2060803@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> <51304BE9.9080206@oracle.com> <5130BBCA.2060803@oracle.com> Message-ID: <5134B9B1.7010707@oracle.com> latest webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.04 joe On 3/1/2013 9:31 AM, JOSEPH PROVINO wrote: > > On 3/1/2013 1:34 AM, David Holmes wrote: >> On 1/03/2013 4:54 AM, JOSEPH PROVINO wrote: >>> Latest webrev is here: >>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 >> >> One lingering glitch: >> >> 3273 if (DumpSharedSpaces || RequireSharedSpaces) { >> 3274 jio_fprintf(defaultStream::error_stream(), >> 3275 "Shared spaces are not supported in this VM\n"); >> 3276 return JNI_ERR; >> 3277 } >> 3278 if (UseSharedSpaces || PrintSharedSpaces) { >> 3279 warning("Shared spaces are not supported in this VM"); >> 3280 } >> 3281 FLAG_SET_DEFAULT(DumpSharedSpaces, false); >> 3282 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >> 3283 FLAG_SET_DEFAULT(PrintSharedSpaces, false); >> >> The last three lines only need to be these two lines: >> >> FLAG_SET_DEFAULT(UseSharedSpaces, false); >> FLAG_SET_DEFAULT(PrintSharedSpaces, false); >> >> and they can move inside the if. > > Okay, I'll make those changes. > > joe > >> >> DumpSharedSpaces and RequireSharedSpaces must already be false else >> we exit at #3276. >> >> David >> ----- >> >>> joe >>> >>> On 2/27/2013 11:36 PM, David Holmes wrote: >>>> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>>>> >>>>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>>>> >>>>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>>>> Latest webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>>>> >>>>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>>>> >>>>>>>>> - confined changes for CDS to filemap.hpp. >>>>>>>> >>>>>>>> These changes are good - thanks. >>>>>>>> >>>>>>>> For arguments.cpp: >>>>>>>> >>>>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>>>> >>>>>>>> If we execute this line then the flag is already false. >>>>>>>> >>>>>>>> Also, as discussed in email -Xshare:dump should probably be an >>>>>>>> error >>>>>>>> not a warning, but note that if left as a warning then this code: >>>>>>>> >>>>>>>> 2518 // -Xshare:dump >>>>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>>>> creates objects >>>>>>>> >>>>>>>> would also force us into intepreter mode, so you would still >>>>>>>> need to >>>>>>>> check INCLUDE_CDS here. >>>>>>> >>>>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>>>> conditional here? >>>>>> >>>>>> ?? You would need the conditional to decide to return JNI_ERR. >>>>> >>>>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >>>> >>>> So I was assuming this was the only place you needed to check this, >>>> but you have to check for -XX:+DumpSharedSpaces as well. So if you >>>> left the -Xshare:dump code alone and later checked for >>>> DumpSharedSpaces and returned with JNI_ERR then it would not matter >>>> that the switch to interpreter mode had already been made. >>>> >>>> David >>>> >>>>> joe >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> joe >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> thanks. >>>>>>>>> >>>>>>>>> joe >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Mon Mar 4 10:07:09 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 04 Mar 2013 13:07:09 -0500 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option In-Reply-To: <512F7BB1.8080105@oracle.com> References: <512F7BB1.8080105@oracle.com> Message-ID: <5134E2CD.6070703@oracle.com> Hi Zhengyu, This looks good except one suggestion. In the lines where CALLER_PC appears twice, it should be called once, assigned to a variable and passed to both of the MemTracker functions, since CALLER_PC will walk the stack and it's not necessary to do it twice in a row. Otherwise, looks good. Coleen On 02/28/2013 10:45 AM, Zhengyu Gu wrote: > NMT did not probably record memory allocations from > os::reserve_memory_special() path, which is usually related to > UseLargePages VM option. > > The symptom of this bug is assertion failure in debug/fastdebug build > or missing Java Heap in NMT output in production build. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 > Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ > > To trigger the failures: > > 1. On Windows, run with -XX:+UseLargePages (with/without > -XX:+UseLargePagesIndividualAllocation) > > 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM > > 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM > > 4. On MacOSX, UseLargePages is disabled. > > Beware that fail to allocate large pages, does not cause JVM to fail. > Instead, JVM will fallback to use regular pages. > > Tests: > Many thanks to Christian T?rnqvist to find capable hardware and > figure out how to get large pages to work. We were able to test the > fix on Solaris sparcv9, Linux x64 and Windows x64. > > > Thanks, > > -Zhengyu > > From zhengyu.gu at oracle.com Mon Mar 4 10:42:03 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 04 Mar 2013 13:42:03 -0500 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option In-Reply-To: <5134E2CD.6070703@oracle.com> References: <512F7BB1.8080105@oracle.com> <5134E2CD.6070703@oracle.com> Message-ID: <5134EAFB.1000406@oracle.com> Thanks! I will make the change. -Zhengyu On 3/4/2013 1:07 PM, Coleen Phillimore wrote: > > Hi Zhengyu, > > This looks good except one suggestion. In the lines where CALLER_PC > appears twice, it should be called once, assigned to a variable and > passed to both of the MemTracker functions, since CALLER_PC will walk > the stack and it's not necessary to do it twice in a row. > > Otherwise, looks good. > Coleen > > On 02/28/2013 10:45 AM, Zhengyu Gu wrote: >> NMT did not probably record memory allocations from >> os::reserve_memory_special() path, which is usually related to >> UseLargePages VM option. >> >> The symptom of this bug is assertion failure in debug/fastdebug build >> or missing Java Heap in NMT output in production build. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 >> Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ >> >> To trigger the failures: >> >> 1. On Windows, run with -XX:+UseLargePages (with/without >> -XX:+UseLargePagesIndividualAllocation) >> >> 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM >> >> 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM >> >> 4. On MacOSX, UseLargePages is disabled. >> >> Beware that fail to allocate large pages, does not cause JVM to fail. >> Instead, JVM will fallback to use regular pages. >> >> Tests: >> Many thanks to Christian T?rnqvist to find capable hardware and >> figure out how to get large pages to work. We were able to test the >> fix on Solaris sparcv9, Linux x64 and Windows x64. >> >> >> Thanks, >> >> -Zhengyu >> >> > From vladimir.kozlov at oracle.com Mon Mar 4 12:12:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Mar 2013 12:12:40 -0800 Subject: Result: Withdraw request for HSX Committer: David Chase In-Reply-To: <512D14C8.7020701@oracle.com> References: <512D14C8.7020701@oracle.com> Message-ID: <51350038.80701@oracle.com> Voting for David Chase [1] is now closed. Yes: 9 Veto: 1 Abstain: 0 The request is withdrawn because of Veto [2]. New CFV will be sent when David Chase contribute more significant changes into Hotspot. Thanks, Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008514.html [2] http://openjdk.java.net/bylaws#lazy-consensus From zhengyu.gu at oracle.com Mon Mar 4 13:37:53 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 04 Mar 2013 16:37:53 -0500 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option In-Reply-To: <5134E2CD.6070703@oracle.com> References: <512F7BB1.8080105@oracle.com> <5134E2CD.6070703@oracle.com> Message-ID: <51351431.7050301@oracle.com> Updated according to Coleen's comment. Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.01/ Thanks, -Zhengyu On 3/4/2013 1:07 PM, Coleen Phillimore wrote: > > Hi Zhengyu, > > This looks good except one suggestion. In the lines where CALLER_PC > appears twice, it should be called once, assigned to a variable and > passed to both of the MemTracker functions, since CALLER_PC will walk > the stack and it's not necessary to do it twice in a row. > > Otherwise, looks good. > Coleen > > On 02/28/2013 10:45 AM, Zhengyu Gu wrote: >> NMT did not probably record memory allocations from >> os::reserve_memory_special() path, which is usually related to >> UseLargePages VM option. >> >> The symptom of this bug is assertion failure in debug/fastdebug build >> or missing Java Heap in NMT output in production build. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 >> Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ >> >> To trigger the failures: >> >> 1. On Windows, run with -XX:+UseLargePages (with/without >> -XX:+UseLargePagesIndividualAllocation) >> >> 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM >> >> 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM >> >> 4. On MacOSX, UseLargePages is disabled. >> >> Beware that fail to allocate large pages, does not cause JVM to fail. >> Instead, JVM will fallback to use regular pages. >> >> Tests: >> Many thanks to Christian T?rnqvist to find capable hardware and >> figure out how to get large pages to work. We were able to test the >> fix on Solaris sparcv9, Linux x64 and Windows x64. >> >> >> Thanks, >> >> -Zhengyu >> >> > From david.holmes at oracle.com Mon Mar 4 18:21:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 12:21:05 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <5134B9B1.7010707@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> <51304BE9.9080206@oracle.com> <5130BBCA.2060803@oracle.com> <5134B9B1.7010707@oracle.com> Message-ID: <51355691.4050806@oracle.com> Thanks Joe. Good to go. David On 5/03/2013 1:11 AM, JOSEPH PROVINO wrote: > latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.04 > > joe > > On 3/1/2013 9:31 AM, JOSEPH PROVINO wrote: >> >> On 3/1/2013 1:34 AM, David Holmes wrote: >>> On 1/03/2013 4:54 AM, JOSEPH PROVINO wrote: >>>> Latest webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 >>> >>> One lingering glitch: >>> >>> 3273 if (DumpSharedSpaces || RequireSharedSpaces) { >>> 3274 jio_fprintf(defaultStream::error_stream(), >>> 3275 "Shared spaces are not supported in this VM\n"); >>> 3276 return JNI_ERR; >>> 3277 } >>> 3278 if (UseSharedSpaces || PrintSharedSpaces) { >>> 3279 warning("Shared spaces are not supported in this VM"); >>> 3280 } >>> 3281 FLAG_SET_DEFAULT(DumpSharedSpaces, false); >>> 3282 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>> 3283 FLAG_SET_DEFAULT(PrintSharedSpaces, false); >>> >>> The last three lines only need to be these two lines: >>> >>> FLAG_SET_DEFAULT(UseSharedSpaces, false); >>> FLAG_SET_DEFAULT(PrintSharedSpaces, false); >>> >>> and they can move inside the if. >> >> Okay, I'll make those changes. >> >> joe >> >>> >>> DumpSharedSpaces and RequireSharedSpaces must already be false else >>> we exit at #3276. >>> >>> David >>> ----- >>> >>>> joe >>>> >>>> On 2/27/2013 11:36 PM, David Holmes wrote: >>>>> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>>>>> >>>>>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>>>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>>>>> >>>>>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>>>>> Latest webrev is here: >>>>>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>>>>> >>>>>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>>>>> >>>>>>>>>> - confined changes for CDS to filemap.hpp. >>>>>>>>> >>>>>>>>> These changes are good - thanks. >>>>>>>>> >>>>>>>>> For arguments.cpp: >>>>>>>>> >>>>>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>>>>> >>>>>>>>> If we execute this line then the flag is already false. >>>>>>>>> >>>>>>>>> Also, as discussed in email -Xshare:dump should probably be an >>>>>>>>> error >>>>>>>>> not a warning, but note that if left as a warning then this code: >>>>>>>>> >>>>>>>>> 2518 // -Xshare:dump >>>>>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>>>>> creates objects >>>>>>>>> >>>>>>>>> would also force us into intepreter mode, so you would still >>>>>>>>> need to >>>>>>>>> check INCLUDE_CDS here. >>>>>>>> >>>>>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>>>>> conditional here? >>>>>>> >>>>>>> ?? You would need the conditional to decide to return JNI_ERR. >>>>>> >>>>>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >>>>> >>>>> So I was assuming this was the only place you needed to check this, >>>>> but you have to check for -XX:+DumpSharedSpaces as well. So if you >>>>> left the -Xshare:dump code alone and later checked for >>>>> DumpSharedSpaces and returned with JNI_ERR then it would not matter >>>>> that the switch to interpreter mode had already been made. >>>>> >>>>> David >>>>> >>>>>> joe >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> joe >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> thanks. >>>>>>>>>> >>>>>>>>>> joe >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From staffan.larsen at oracle.com Mon Mar 4 23:24:46 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 5 Mar 2013 08:24:46 +0100 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Message-ID: A very small fix for a warning. webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ Thanks, /Staffan From david.holmes at oracle.com Mon Mar 4 23:39:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 17:39:53 +1000 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: References: Message-ID: <5135A149.3040608@oracle.com> Looks fine to me - thanks Staffan! David On 5/03/2013 5:24 PM, Staffan Larsen wrote: > A very small fix for a warning. > > webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ > > Thanks, > /Staffan > From serguei.spitsyn at oracle.com Tue Mar 5 01:18:05 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 05 Mar 2013 01:18:05 -0800 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: References: Message-ID: <5135B84D.9020401@oracle.com> Looks good. Thanks, Serguei On 3/4/13 11:24 PM, Staffan Larsen wrote: > A very small fix for a warning. > > webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ > > Thanks, > /Staffan From mikael.vidstedt at oracle.com Tue Mar 5 09:04:21 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 05 Mar 2013 09:04:21 -0800 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: References: Message-ID: <51362595.3000402@oracle.com> Looks good! Cheers, Mikael On 2013-03-04 23:24, Staffan Larsen wrote: > A very small fix for a warning. > > webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ > > Thanks, > /Staffan From coleen.phillimore at oracle.com Tue Mar 5 11:30:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 05 Mar 2013 14:30:06 -0500 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <5134FDEF.4030007@oracle.com> References: <5134FDEF.4030007@oracle.com> Message-ID: <513647BE.20504@oracle.com> Adding hotspot-dev to get some more potential reviewers from maybe the GC team, hint... Coleen On 03/04/2013 03:02 PM, Coleen Phillimore wrote: > Summary: Zero metadata in constructors, not in allocation (and some in > constructors) > > This seems like a good first step in passing initial values into > constructors and no initializing metadata types by the callers > (although a lot more parameters will have to be passed for some). > > Tested with runThese jck, NSK vm.quick.testlist, lang and vm jck8, > java/lang/annotation jtreg tests and java/lang/invoke jtreg tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Tue Mar 5 11:30:46 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 05 Mar 2013 14:30:46 -0500 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <51350056.7020805@oracle.com> References: <51350056.7020805@oracle.com> Message-ID: <513647E6.3080908@oracle.com> Resend to hotspot-dev. I don't think anyone reads hotspot-runtime-dev anymore. Please review!! Thanks, Coleen On 03/04/2013 03:13 PM, Coleen Phillimore wrote: > Summary: Store metadata on ClassFileParser instance to be cleaned up > by destructor. This enabled some refactoring of the enormous > parseClassFile function. > > Note: I moved out code that lays out the java object into it's own > function, but the diffs made it look like I made more than minor > changes. The changes I made was changing class_name to _class_name > and cp to _cp, and not more than that. To see these changes, you'll > have to look at before/after code and not the diffs. I also tried > moving this layout_fields() function around to it wouldn't false match > but I wanted to keep it next to parseClassFile() and not move it too > far away. > > Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, > java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Tue Mar 5 11:45:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 05 Mar 2013 14:45:06 -0500 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option In-Reply-To: <51351431.7050301@oracle.com> References: <512F7BB1.8080105@oracle.com> <5134E2CD.6070703@oracle.com> <51351431.7050301@oracle.com> Message-ID: <51364B42.9070300@oracle.com> Looks good to me. Nice job digging up how to test on all the platforms. Coleen On 03/04/2013 04:37 PM, Zhengyu Gu wrote: > Updated according to Coleen's comment. > > Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.01/ > > Thanks, > > -Zhengyu > > > On 3/4/2013 1:07 PM, Coleen Phillimore wrote: >> >> Hi Zhengyu, >> >> This looks good except one suggestion. In the lines where CALLER_PC >> appears twice, it should be called once, assigned to a variable and >> passed to both of the MemTracker functions, since CALLER_PC will walk >> the stack and it's not necessary to do it twice in a row. >> >> Otherwise, looks good. >> Coleen >> >> On 02/28/2013 10:45 AM, Zhengyu Gu wrote: >>> NMT did not probably record memory allocations from >>> os::reserve_memory_special() path, which is usually related to >>> UseLargePages VM option. >>> >>> The symptom of this bug is assertion failure in debug/fastdebug >>> build or missing Java Heap in NMT output in production build. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 >>> Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ >>> >>> To trigger the failures: >>> >>> 1. On Windows, run with -XX:+UseLargePages (with/without >>> -XX:+UseLargePagesIndividualAllocation) >>> >>> 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM >>> >>> 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM >>> >>> 4. On MacOSX, UseLargePages is disabled. >>> >>> Beware that fail to allocate large pages, does not cause JVM to >>> fail. Instead, JVM will fallback to use regular pages. >>> >>> Tests: >>> Many thanks to Christian T?rnqvist to find capable hardware and >>> figure out how to get large pages to work. We were able to test the >>> fix on Solaris sparcv9, Linux x64 and Windows x64. >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >> > From bill.pittore at oracle.com Tue Mar 5 15:05:39 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 05 Mar 2013 18:05:39 -0500 Subject: Request for review- RFE 8005716 Message-ID: <51367A43.1060606@oracle.com> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. The JEP is here: http://openjdk.java.net/jeps/178 The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 The webrevs are here: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. thanks, bill From dean.long at oracle.com Tue Mar 5 15:08:57 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 15:08:57 -0800 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <5135A149.3040608@oracle.com> References: <5135A149.3040608@oracle.com> Message-ID: <51367B09.8030008@oracle.com> What if allocate_init_map() fails to allocate memory? Shouldn't add_class_share_map_info() follow the pattern of add_map_info(): return NULL or "map", and have the caller check for NULL? dl On 3/4/2013 11:39 PM, David Holmes wrote: > Looks fine to me - thanks Staffan! > > David > > On 5/03/2013 5:24 PM, Staffan Larsen wrote: >> A very small fix for a warning. >> >> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >> >> Thanks, >> /Staffan >> From david.holmes at oracle.com Tue Mar 5 15:23:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 09:23:27 +1000 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <51367B09.8030008@oracle.com> References: <5135A149.3040608@oracle.com> <51367B09.8030008@oracle.com> Message-ID: <51367E6F.8030103@oracle.com> On 6/03/2013 9:08 AM, Dean Long wrote: > What if allocate_init_map() fails to allocate memory? Shouldn't > add_class_share_map_info() follow the pattern of add_map_info(): > return NULL or "map", and have the caller check for NULL? AFAICS apart from one seeming bug, if we can't allocate a new map it does no harm in terms of the code that looks at the map. The bug is: 177 mp = ph->core->class_share_maps; 178 if (mp) { 179 print_debug("can't locate map_info at 0x%lx, trying class share maps\n", 180 addr); where I think 178 should be "if (mp==NULL)". Everything else will just do nothing upon encountering a NULL map. The fix addresses the parfait warning and leaves the code functionally unchanged. So any robustness issues would need to be done via a follow up RFE. David > dl > > On 3/4/2013 11:39 PM, David Holmes wrote: >> Looks fine to me - thanks Staffan! >> >> David >> >> On 5/03/2013 5:24 PM, Staffan Larsen wrote: >>> A very small fix for a warning. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >>> >>> Thanks, >>> /Staffan >>> > From dean.long at oracle.com Tue Mar 5 16:36:24 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 16:36:24 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <51368F88.8000309@oracle.com> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on Windows, you can't just turn that into "_JNI_OnLoad at 8_" + . I think it needs to be "_JNI_OnLoad_" + + "@8" Looks like onLoadSymbols[] is unused in Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). Instead of adding getProcessHandle(), why not add JVM_FindBuiltinLibraryEntry() instead? This would make it easier to support table-lookup when runtime symbol information is missing or not supported by the platform. dl On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' > has been statically linked into the VM. If the symbol is found, it is > assumed that the library is linked in and will not be dynamically loaded. > > thanks, > bill From dean.long at oracle.com Tue Mar 5 16:44:56 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 16:44:56 -0800 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <51367E6F.8030103@oracle.com> References: <5135A149.3040608@oracle.com> <51367B09.8030008@oracle.com> <51367E6F.8030103@oracle.com> Message-ID: <51369188.8090304@oracle.com> On 3/5/2013 3:23 PM, David Holmes wrote: > On 6/03/2013 9:08 AM, Dean Long wrote: >> What if allocate_init_map() fails to allocate memory? Shouldn't >> add_class_share_map_info() follow the pattern of add_map_info(): >> return NULL or "map", and have the caller check for NULL? > > AFAICS apart from one seeming bug, if we can't allocate a new map it > does no harm in terms of the code that looks at the map. The bug is: > > 177 mp = ph->core->class_share_maps; > 178 if (mp) { > 179 print_debug("can't locate map_info at 0x%lx, trying class > share maps\n", > 180 addr); > > where I think 178 should be "if (mp==NULL)". Everything else will just > do nothing upon encountering a NULL map. > > The fix addresses the parfait warning and leaves the code functionally > unchanged. So any robustness issues would need to be done via a follow > up RFE. > Why not just add "return map" at the end of the function? It seems closer to the intent of the original code, assuming it addresses the parfait warning. dl > David > >> dl >> >> On 3/4/2013 11:39 PM, David Holmes wrote: >>> Looks fine to me - thanks Staffan! >>> >>> David >>> >>> On 5/03/2013 5:24 PM, Staffan Larsen wrote: >>>> A very small fix for a warning. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >>>> >>>> Thanks, >>>> /Staffan >>>> >> From david.holmes at oracle.com Tue Mar 5 16:48:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 10:48:56 +1000 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <51369188.8090304@oracle.com> References: <5135A149.3040608@oracle.com> <51367B09.8030008@oracle.com> <51367E6F.8030103@oracle.com> <51369188.8090304@oracle.com> Message-ID: <51369278.5060409@oracle.com> On 6/03/2013 10:44 AM, Dean Long wrote: > On 3/5/2013 3:23 PM, David Holmes wrote: >> On 6/03/2013 9:08 AM, Dean Long wrote: >>> What if allocate_init_map() fails to allocate memory? Shouldn't >>> add_class_share_map_info() follow the pattern of add_map_info(): >>> return NULL or "map", and have the caller check for NULL? >> >> AFAICS apart from one seeming bug, if we can't allocate a new map it >> does no harm in terms of the code that looks at the map. The bug is: >> >> 177 mp = ph->core->class_share_maps; >> 178 if (mp) { >> 179 print_debug("can't locate map_info at 0x%lx, trying class >> share maps\n", >> 180 addr); >> >> where I think 178 should be "if (mp==NULL)". Everything else will just >> do nothing upon encountering a NULL map. >> >> The fix addresses the parfait warning and leaves the code functionally >> unchanged. So any robustness issues would need to be done via a follow >> up RFE. >> > Why not just add "return map" at the end of the function? It seems > closer to the intent of the original code, assuming it > addresses the parfait warning. Nothing expects a return value from that function so what point is there in returning something? I would expect that to simply produce another warning/error about a function return value being ignored. David ----- > > dl > >> David >> >>> dl >>> >>> On 3/4/2013 11:39 PM, David Holmes wrote: >>>> Looks fine to me - thanks Staffan! >>>> >>>> David >>>> >>>> On 5/03/2013 5:24 PM, Staffan Larsen wrote: >>>>> A very small fix for a warning. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>> > From dean.long at oracle.com Tue Mar 5 17:37:01 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 17:37:01 -0800 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <51369278.5060409@oracle.com> References: <5135A149.3040608@oracle.com> <51367B09.8030008@oracle.com> <51367E6F.8030103@oracle.com> <51369188.8090304@oracle.com> <51369278.5060409@oracle.com> Message-ID: <51369DBD.6030309@oracle.com> On 3/5/2013 4:48 PM, David Holmes wrote: > On 6/03/2013 10:44 AM, Dean Long wrote: >> On 3/5/2013 3:23 PM, David Holmes wrote: >>> On 6/03/2013 9:08 AM, Dean Long wrote: >>>> What if allocate_init_map() fails to allocate memory? Shouldn't >>>> add_class_share_map_info() follow the pattern of add_map_info(): >>>> return NULL or "map", and have the caller check for NULL? >>> >>> AFAICS apart from one seeming bug, if we can't allocate a new map it >>> does no harm in terms of the code that looks at the map. The bug is: >>> >>> 177 mp = ph->core->class_share_maps; >>> 178 if (mp) { >>> 179 print_debug("can't locate map_info at 0x%lx, trying class >>> share maps\n", >>> 180 addr); >>> >>> where I think 178 should be "if (mp==NULL)". Everything else will just >>> do nothing upon encountering a NULL map. >>> >>> The fix addresses the parfait warning and leaves the code functionally >>> unchanged. So any robustness issues would need to be done via a follow >>> up RFE. >>> >> Why not just add "return map" at the end of the function? It seems >> closer to the intent of the original code, assuming it >> addresses the parfait warning. > > Nothing expects a return value from that function so what point is > there in returning something? I would expect that to simply produce > another warning/error about a function return value being ignored. > If it complains about that then wouldn't we need to put (void) in front of all calls to strcat(), for example? Anyway, I'm OK with the current change if Staffan files an RFE for other issue. dl > David > ----- > >> >> dl >> >>> David >>> >>>> dl >>>> >>>> On 3/4/2013 11:39 PM, David Holmes wrote: >>>>> Looks fine to me - thanks Staffan! >>>>> >>>>> David >>>>> >>>>> On 5/03/2013 5:24 PM, Staffan Larsen wrote: >>>>>> A very small fix for a warning. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>> >> From daniel.daugherty at oracle.com Tue Mar 5 18:27:02 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 06 Mar 2013 02:27:02 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20130306022736.9C69D47879@hg.openjdk.java.net> Changeset: 1f9994892f89 Author: stefank Date: 2013-02-21 17:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f9994892f89 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders. Reviewed-by: coleenp, acorn Contributed-by: Stefan Karlsson , Erik Helin ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3c9db54c2660 Author: mikael Date: 2013-02-26 08:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c9db54c2660 8008081: Print outs do not have matching arguments Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function Reviewed-by: sla, dholmes ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/memReporter.cpp ! src/share/vm/utilities/numberSeq.cpp Changeset: 05f2fc6b4ea7 Author: dholmes Date: 2013-02-27 04:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/05f2fc6b4ea7 Merge Changeset: 96bd4772ec62 Author: kevinw Date: 2013-02-27 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96bd4772ec62 8008807: SA: jstack crash when target has mismatched bitness (Linux) Reviewed-by: rbackman, sla, poonam ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 698b615a1cde Author: kevinw Date: 2013-02-27 16:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/698b615a1cde Merge Changeset: 651919d134f7 Author: kevinw Date: 2013-02-27 22:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/651919d134f7 7178741: SA: jstack -m produce UnalignedAddressException in output (Linux) Reviewed-by: poonam, sla ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java Changeset: 5ee250974db9 Author: dcubed Date: 2013-02-27 15:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ee250974db9 8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock. Reviewed-by: sla, acorn ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/threadService.cpp Changeset: a140cd925462 Author: dcubed Date: 2013-02-28 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a140cd925462 Merge Changeset: 63e54c37ac64 Author: simonis Date: 2013-02-27 09:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/63e54c37ac64 8008959: Fix non-PCH build on Linux, Windows and MacOS X Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files. Reviewed-by: coleenp, stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: a506ac816f14 Author: coleenp Date: 2013-02-27 07:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a506ac816f14 Merge Changeset: 143973ced9ab Author: coleenp Date: 2013-02-28 18:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/143973ced9ab Merge Changeset: 3e83d69c19db Author: dcubed Date: 2013-03-01 15:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3e83d69c19db Merge From bill.pittore at oracle.com Tue Mar 5 20:13:31 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 05 Mar 2013 23:13:31 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <51368F88.8000309@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> Message-ID: <5136C26B.7000805@oracle.com> On 3/5/2013 7:36 PM, Dean Long wrote: > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > "_JNI_OnLoad_" + + "@8" I'll look into that. When I built for windows and ran our test, the JNI_OnLoad_TestStaticLib was exported without the decoration just based on the JNIEXPORT JNICALL specifiers on the function. I didn't do anything special to export it. But I recall this problem from another project. 1 0 00001014 JNI_OnLoad_TestStaticLib = @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). I'll remove that. I redid the call to findBuiltinJniFunction but forgot to remove that. > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > This would make it easier to support table-lookup when runtime symbol > information is missing or not > supported by the platform. Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() an exported function in the VM? How does it find JNI_OnLoad_L? Via a table setup by the developer/build system when the library is linked in? bill > > dl > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support >> for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of >> JNI_OnLoad_libname to determine if the library specified by 'libname' >> has been statically linked into the VM. If the symbol is found, it is >> assumed that the library is linked in and will not be dynamically >> loaded. >> >> thanks, >> bill > From jon.masamitsu at oracle.com Tue Mar 5 21:26:36 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 05 Mar 2013 21:26:36 -0800 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <513647BE.20504@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> Message-ID: <5136D38C.9040100@oracle.com> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html *- ConstantPoolCache* ConstantPoolCache::allocate(ClassLoaderData* loader_data, int length, TRAPS) {* *+ int length,* *+ const intStack& index_map,* *+ const intStack& invokedynamic_map, TRAPS) { * Why did you not move the TRAP parameter to a new line? http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html Did you remove the TieredCompilation test *if (TieredCompilation) { * for consistency of initialization? http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html * #ifndef PRODUCT* * int _verify_count; // to avoid redundant verifies* * #endif* Not concerned about redundant verifies anymore? Rest looks good. Jon On 3/5/2013 11:30 AM, Coleen Phillimore wrote: > > Adding hotspot-dev to get some more potential reviewers from maybe the > GC team, hint... > > Coleen > > On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >> Summary: Zero metadata in constructors, not in allocation (and some >> in constructors) >> >> This seems like a good first step in passing initial values into >> constructors and no initializing metadata types by the callers >> (although a lot more parameters will have to be passed for some). >> >> Tested with runThese jck, NSK vm.quick.testlist, lang and vm jck8, >> java/lang/annotation jtreg tests and java/lang/invoke jtreg tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >> >> Thanks, >> Coleen >> >> > From dean.long at oracle.com Tue Mar 5 21:54:06 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 05 Mar 2013 21:54:06 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5136D9FE.5040009@oracle.com> On 3/5/2013 8:13 PM, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) >> >> Looks like onLoadSymbols[] is unused in >> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > I'll remove that. I redid the call to findBuiltinJniFunction but > forgot to remove that. > >> >> Instead of adding getProcessHandle(), why not add >> JVM_FindBuiltinLibraryEntry() instead? >> This would make it easier to support table-lookup when runtime symbol >> information is missing or not >> supported by the platform. > Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() > an exported function in the VM? How does it find JNI_OnLoad_L? For Windows and Linux, it would use basically your same code, just refactored a little. By the way, did you consider using the special RTLD_DEFAULT handle instead of dlopen(NULL)? > Via a table setup by the developer/build system when the library is > linked in? > Yes, in previous projects we did exactly that for more exotic OSes. dl > bill > >> >> dl >> >> On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >>> This request is tied to bugid 8005716 that deals with adding support >>> for statically linked JNI libraries. >>> >>> The JEP is here: http://openjdk.java.net/jeps/178 >>> >>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >>> >>> The webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >>> >>> The main piece of functionality is to check for the presence of >>> JNI_OnLoad_libname to determine if the library specified by >>> 'libname' has been statically linked into the VM. If the symbol is >>> found, it is assumed that the library is linked in and will not be >>> dynamically loaded. >>> >>> thanks, >>> bill >> > From rednaxelafx at gmail.com Tue Mar 5 22:07:43 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 6 Mar 2013 14:07:43 +0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <01d201ce19eb$332d5160$9987f420$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: Hi Uwe, If you can attach gdb onto it, and jstack -m and jstack -F should also work; that'll get you the Java stack trace. (But it probably doesn't matter in this case, because the hang is probably bug in the VM). - Kris On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: > Hi, > > since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). > > JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). > > I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. > > To reproduce: > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) > - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) > - change to directory lucene/analysis/uima and run: > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" > > I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > From david.holmes at oracle.com Tue Mar 5 23:52:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 17:52:26 +1000 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: <5136F5BA.7010409@oracle.com> If the VM is completely unresponsive then it suggests we are at a safepoint. The GC threads are not "hung" in os::parK, they are parked - waiting to be notified of something. The thing is to find out why they are not being woken up. Can the gdb log be posted somewhere? I don't know if the attachment made it to the original posting on hotspot-gc but it's no longer available on hotspot-dev. Thanks, David On 6/03/2013 4:07 PM, Krystal Mok wrote: > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F should also > work; that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is > probably bug in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: >> Hi, >> >> since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). >> >> JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). >> >> I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. >> >> To reproduce: >> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) >> - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) >> - change to directory lucene/analysis/uima and run: >> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test >> After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" >> >> I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> Apache Lucene PMC Member / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >> From dweiss at apache.org Tue Mar 5 23:55:28 2013 From: dweiss at apache.org (Dawid Weiss) Date: Wed, 6 Mar 2013 08:55:28 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F5BA.7010409@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> Message-ID: Here you go: http://pastebin.com/raw.php?i=b2PHLm1e Dawid On Wed, Mar 6, 2013 at 8:52 AM, David Holmes wrote: > If the VM is completely unresponsive then it suggests we are at a > safepoint. > > The GC threads are not "hung" in os::parK, they are parked - waiting to be > notified of something. > > The thing is to find out why they are not being woken up. > > Can the gdb log be posted somewhere? I don't know if the attachment made > it to the original posting on hotspot-gc but it's no longer available on > hotspot-dev. > > Thanks, > David > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > >> Hi Uwe, >> >> If you can attach gdb onto it, and jstack -m and jstack -F should also >> work; that'll get you the Java stack trace. >> (But it probably doesn't matter in this case, because the hang is >> probably bug in the VM). >> >> - Kris >> >> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >> wrote: >> >>> Hi, >>> >>> since a few month we are extensively testing various preview builds of >>> JDK 8 for compatibility with Apache Lucene and Solr, so we can find any >>> bugs early and prevent the problems we had with the release of Java 7 two >>> years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that >>> has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) >>> installed, choosing a different one with different hotspot and garbage >>> collector settings on every run of the test suite (which takes approx. >>> 30-45 minutes). >>> >>> JDK 8 b79 works so far very well on Linux, we found some strange >>> behavior in early versions (maybe compiler errors), but no longer at the >>> moment. There is one configuration that constantly and reproducibly hangs >>> in one module that is tested: The configuration uses JDK 8 b79 (same for >>> b78), 32 bit, and G1GC (server or client does not matter). The JVM running >>> the tests hangs irresponsible (jstack or kill -3 have no effect/cannot >>> connect, standard kill does not stop it, only kill -9 actually kills it). >>> It can be reproduced in this Lucene module 100% (it hangs always). >>> >>> I was able to connect with GDB to the JVM and get a stack trace on all >>> threads (see attachment, dump.txt). As you see all threads of G1GC seem to >>> hang in a syscall (os:park(), a conditional wait in pthread library). >>> Unfortunately that?s all I can give you. A Java stacktrace is not possible >>> because the JVM reacts on neither kill -3 nor jstack. With all other >>> garbage collectors it passes the test without hangs in a few seconds, with >>> 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, >>> so only the 32 bit variant is affected. Client or Server VM makes no >>> difference. >>> >>> To reproduce: >>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should >>> not matter) >>> - Download Lucene Source code (e.g. the snapshot version we were testing >>> with: https://builds.apache.org/job/**Lucene-Artifacts-trunk/2212/** >>> artifact/lucene/dist/ >>> ) >>> - change to directory lucene/analysis/uima and run: >>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>> -Dtests.jvms=1 test >>> After a while the test framework prints "stalled" messages (because the >>> child VM actually running the test no longer responds). The PID is also >>> printed. Try to get a stack trace or kill it, no response. Only kill -9 >>> helps. Choosing another garbage collector in the above command line makes >>> the test finish after a few seconds, e.g. -Dargs="-server >>> -XX:+UseConcMarkSweepGC" >>> >>> I posted this bug report directly to the mailing list, because with >>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>> there is no response from any reviewer after several weeks and we were able >>> to help to find and fix javadoc and javac-compiler bugs early. So I hope >>> you can help for this bug, too. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> Apache Lucene PMC Member / Committer >>> Bremen, Germany >>> http://lucene.apache.org/ >>> >>> >>> > From uschindler at apache.org Tue Mar 5 13:48:40 2013 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 5 Mar 2013 22:48:40 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Message-ID: <01d201ce19eb$332d5160$9987f420$@apache.org> Hi, since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. To reproduce: - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) - change to directory lucene/analysis/uima and run: ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dump.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20130305/d1680675/dump-0001.txt From uschindler at apache.org Wed Mar 6 02:12:09 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 11:12:09 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: <008f01ce1a53$103416e0$309c44a0$@apache.org> Thanks, I'll try to use jstack with -F or -m! Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Krystal Mok [mailto:rednaxelafx at gmail.com] > Sent: Wednesday, March 06, 2013 7:08 AM > To: Uwe Schindler > Cc: hotspot-gc-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > Dawid Weiss; dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F should also work; > that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is probably bug > in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > wrote: > > Hi, > > > > since a few month we are extensively testing various preview builds of JDK > 8 for compatibility with Apache Lucene and Solr, so we can find any bugs > early and prevent the problems we had with the release of Java 7 two years > ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has > various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, > choosing a different one with different hotspot and garbage collector > settings on every run of the test suite (which takes approx. 30-45 minutes). > > > > JDK 8 b79 works so far very well on Linux, we found some strange behavior > in early versions (maybe compiler errors), but no longer at the moment. > There is one configuration that constantly and reproducibly hangs in one > module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 > bit, and G1GC (server or client does not matter). The JVM running the tests > hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard > kill does not stop it, only kill -9 actually kills it). It can be reproduced in this > Lucene module 100% (it hangs always). > > > > I was able to connect with GDB to the JVM and get a stack trace on all > threads (see attachment, dump.txt). As you see all threads of G1GC seem to > hang in a syscall (os:park(), a conditional wait in pthread library). > Unfortunately that?s all I can give you. A Java stacktrace is not possible > because the JVM reacts on neither kill -3 nor jstack. With all other garbage > collectors it passes the test without hangs in a few seconds, with 32 bit G1GC > it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit > variant is affected. Client or Server VM makes no difference. > > > > To reproduce: > > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > > should not matter) > > - Download Lucene Source code (e.g. the snapshot version we were > > testing with: > > https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/luc > > ene/dist/) > > - change to directory lucene/analysis/uima and run: > > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test After a while the test framework prints "stalled" > messages (because the child VM actually running the test no longer > responds). The PID is also printed. Try to get a stack trace or kill it, no > response. Only kill -9 helps. Choosing another garbage collector in the above > command line makes the test finish after a few seconds, e.g. -Dargs="-server > -XX:+UseConcMarkSweepGC" > > > > I posted this bug report directly to the mailing list, because with earlier bug > reports, there seem to be a problem with bugs.sun.com - there is no > response from any reviewer after several weeks and we were able to help to > find and fix javadoc and javac-compiler bugs early. So I hope you can help for > this bug, too. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org For additional > commands, e-mail: dev-help at lucene.apache.org From david.holmes at oracle.com Wed Mar 6 02:23:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 20:23:10 +1000 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> Message-ID: <5137190E.1060504@oracle.com> On 6/03/2013 5:55 PM, Dawid Weiss wrote: > > Here you go: > http://pastebin.com/raw.php?i=b2PHLm1e Thanks. I would have to say this seems to be the suspicious part: Thread 22 (Thread 0xf20ffb40 (LWP 22939)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5fb16 in SuspendibleThreadSet::join() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b5ea41 in ConcurrentG1RefineThread::run_young_rs_sampling() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6b5ef91 in ConcurrentG1RefineThread::run() () The suspendible thread set logic looks 'tricky". Time for the G1 experts to take over. :) David > Dawid > > On Wed, Mar 6, 2013 at 8:52 AM, David Holmes > wrote: > > If the VM is completely unresponsive then it suggests we are at a > safepoint. > > The GC threads are not "hung" in os::parK, they are parked - waiting > to be notified of something. > > The thing is to find out why they are not being woken up. > > Can the gdb log be posted somewhere? I don't know if the attachment > made it to the original posting on hotspot-gc but it's no longer > available on hotspot-dev. > > Thanks, > David > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F > should also > work; that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is > probably bug in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > > wrote: > > Hi, > > since a few month we are extensively testing various preview > builds of JDK 8 for compatibility with Apache Lucene and > Solr, so we can find any bugs early and prevent the problems > we had with the release of Java 7 two years ago. Currently > we have a Linux (Ubuntu 64bit) Jenkins machine that has > various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older > JRockit) installed, choosing a different one with different > hotspot and garbage collector settings on every run of the > test suite (which takes approx. 30-45 minutes). > > JDK 8 b79 works so far very well on Linux, we found some > strange behavior in early versions (maybe compiler errors), > but no longer at the moment. There is one configuration that > constantly and reproducibly hangs in one module that is > tested: The configuration uses JDK 8 b79 (same for b78), 32 > bit, and G1GC (server or client does not matter). The JVM > running the tests hangs irresponsible (jstack or kill -3 > have no effect/cannot connect, standard kill does not stop > it, only kill -9 actually kills it). It can be reproduced in > this Lucene module 100% (it hangs always). > > I was able to connect with GDB to the JVM and get a stack > trace on all threads (see attachment, dump.txt). As you see > all threads of G1GC seem to hang in a syscall (os:park(), a > conditional wait in pthread library). Unfortunately that?s > all I can give you. A Java stacktrace is not possible > because the JVM reacts on neither kill -3 nor jstack. With > all other garbage collectors it passes the test without > hangs in a few seconds, with 32 bit G1GC it can stand still > for hours. The 64 bit JVM passes with G1GC, so only the 32 > bit variant is affected. Client or Server VM makes no > difference. > > To reproduce: > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but > this should not matter) > - Download Lucene Source code (e.g. the snapshot version we > were testing with: > https://builds.apache.org/job/__Lucene-Artifacts-trunk/2212/__artifact/lucene/dist/ > ) > - change to directory lucene/analysis/uima and run: > ant -Dargs="-server -XX:+UseG1GC" > -Dtests.multiplier=3 -Dtests.jvms=1 test > After a while the test framework prints "stalled" messages > (because the child VM actually running the test no longer > responds). The PID is also printed. Try to get a stack trace > or kill it, no response. Only kill -9 helps. Choosing > another garbage collector in the above command line makes > the test finish after a few seconds, e.g. -Dargs="-server > -XX:+UseConcMarkSweepGC" > > I posted this bug report directly to the mailing list, > because with earlier bug reports, there seem to be a problem > with bugs.sun.com - there is no > response from any reviewer after several weeks and we were > able to help to find and fix javadoc and javac-compiler bugs > early. So I hope you can help for this bug, too. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > From thomas.schatzl at oracle.com Wed Mar 6 03:18:08 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 12:18:08 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5137190E.1060504@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5137190E.1060504@oracle.com> Message-ID: <1362568688.2599.15.camel@cirrus> Hi, On Wed, 2013-03-06 at 20:23 +1000, David Holmes wrote: > On 6/03/2013 5:55 PM, Dawid Weiss wrote: > > > > Here you go: > > http://pastebin.com/raw.php?i=b2PHLm1e > > Thanks. I would have to say this seems to be the suspicious part: > > Thread 22 (Thread 0xf20ffb40 (LWP 22939)): [...] > from > /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so > #6 0xf6b5ea41 in ConcurrentG1RefineThread::run_young_rs_sampling() () > from > The suspendible thread set logic looks 'tricky". Time for the G1 experts > to take over. :) The young gen rs sampling thread is a thread that does some statistical updates while the application is running. So that in the STW pause not so much work needs to be done. At a safepoint it is always suspended, this is normal. As Bengt mentioned, the problem seems to be thread 10, which is the VM thread (the one responsible for bringing everything to a safepoint and then distributing work). According to the stack trace, this thread seems to be waiting for synchronization with the marking threads because of a mark stack overflow during weak reference processing. However all marking threads are already waiting due to the safepointing operation, and so it waits endlessly. As Bengt mentioned, this thread shouldn't be waiting, and shouldn't need to because it seems to be the only thread working on weak references anyway (i.e. this phase is single threaded). (All imo) Thomas From bengt.rutisson at oracle.com Wed Mar 6 04:08:17 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 13:08:17 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F888.6010501@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> Message-ID: <513731B1.1090708@oracle.com> Hi all, I sent this email earlier, but I did "reply list" instead of "reply all". Sorry about that. The hang is due to the fact that we are using single threaded reference processing but end up in the multi threaded code path and get stuck in a loop that waits for the other processing threads to terminate. John Cuthbertson is working on a fix for this. I think we have all the information we need to solve this. Bengt On 3/6/13 9:04 AM, Bengt Rutisson wrote: > > David, > > I think this is a VM bug and the thread dumps that Uwe produced are > enough to start tracking down the root cause. > > On 3/6/13 8:52 AM, David Holmes wrote: >> If the VM is completely unresponsive then it suggests we are at a >> safepoint. > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > >> >> The GC threads are not "hung" in os::parK, they are parked - waiting >> to be notified of something. > > It looks like the reference processing thread is stuck in a loop where > it does wait(). So, the VM is hanging even if that stack trace also > ends up in os::park(). > >> >> The thing is to find out why they are not being woken up. > > Actually, in this case we should probably not even be calling wait... > >> >> Can the gdb log be posted somewhere? I don't know if the attachment >> made it to the original posting on hotspot-gc but it's no longer >> available on hotspot-dev. > > I received the attachment with the original email. I've attached it to > the bug report that I created: 8009536. You can find it there if you > want to. But I think we have a fairly good idea of what change caused > the hang. > > Bengt > >> >> Thanks, >> David >> >> On 6/03/2013 4:07 PM, Krystal Mok wrote: >>> Hi Uwe, >>> >>> If you can attach gdb onto it, and jstack -m and jstack -F should also >>> work; that'll get you the Java stack trace. >>> (But it probably doesn't matter in this case, because the hang is >>> probably bug in the VM). >>> >>> - Kris >>> >>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >>> wrote: >>>> Hi, >>>> >>>> since a few month we are extensively testing various preview builds >>>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can >>>> find any bugs early and prevent the problems we had with the >>>> release of Java 7 two years ago. Currently we have a Linux (Ubuntu >>>> 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 >>>> snapshot, IBM J9, older JRockit) installed, choosing a different >>>> one with different hotspot and garbage collector settings on every >>>> run of the test suite (which takes approx. 30-45 minutes). >>>> >>>> JDK 8 b79 works so far very well on Linux, we found some strange >>>> behavior in early versions (maybe compiler errors), but no longer >>>> at the moment. There is one configuration that constantly and >>>> reproducibly hangs in one module that is tested: The configuration >>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>>> does not matter). The JVM running the tests hangs irresponsible >>>> (jstack or kill -3 have no effect/cannot connect, standard kill >>>> does not stop it, only kill -9 actually kills it). It can be >>>> reproduced in this Lucene module 100% (it hangs always). >>>> >>>> I was able to connect with GDB to the JVM and get a stack trace on >>>> all threads (see attachment, dump.txt). As you see all threads of >>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>>> pthread library). Unfortunately that?s all I can give you. A Java >>>> stacktrace is not possible because the JVM reacts on neither kill >>>> -3 nor jstack. With all other garbage collectors it passes the test >>>> without hangs in a few seconds, with 32 bit G1GC it can stand still >>>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit >>>> variant is affected. Client or Server VM makes no difference. >>>> >>>> To reproduce: >>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>>> should not matter) >>>> - Download Lucene Source code (e.g. the snapshot version we were >>>> testing with: >>>> https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) >>>> - change to directory lucene/analysis/uima and run: >>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>>> -Dtests.jvms=1 test >>>> After a while the test framework prints "stalled" messages (because >>>> the child VM actually running the test no longer responds). The PID >>>> is also printed. Try to get a stack trace or kill it, no response. >>>> Only kill -9 helps. Choosing another garbage collector in the above >>>> command line makes the test finish after a few seconds, e.g. >>>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>>> >>>> I posted this bug report directly to the mailing list, because with >>>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>>> there is no response from any reviewer after several weeks and we >>>> were able to help to find and fix javadoc and javac-compiler bugs >>>> early. So I hope you can help for this bug, too. >>>> >>>> Uwe >>>> >>>> ----- >>>> Uwe Schindler >>>> uschindler at apache.org >>>> Apache Lucene PMC Member / Committer >>>> Bremen, Germany >>>> http://lucene.apache.org/ >>>> >>>> > From uschindler at apache.org Wed Mar 6 04:49:07 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 13:49:07 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <513731B1.1090708@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> Message-ID: <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> Hi Bengt, That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev- > bounces at openjdk.java.net] On Behalf Of Bengt Rutisson > Sent: Wednesday, March 06, 2013 1:08 PM > To: hotspot-gc-dev at openjdk.java.net; David Holmes; Dawid Weiss; hotspot- > dev at openjdk.java.net > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > > Hi all, > > I sent this email earlier, but I did "reply list" instead of "reply all". Sorry about > that. > > The hang is due to the fact that we are using single threaded reference > processing but end up in the multi threaded code path and get stuck in a loop > that waits for the other processing threads to terminate. > > John Cuthbertson is working on a fix for this. I think we have all the > information we need to solve this. > > Bengt > > On 3/6/13 9:04 AM, Bengt Rutisson wrote: > > > > David, > > > > I think this is a VM bug and the thread dumps that Uwe produced are > > enough to start tracking down the root cause. > > > > On 3/6/13 8:52 AM, David Holmes wrote: > >> If the VM is completely unresponsive then it suggests we are at a > >> safepoint. > > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > > >> > >> The GC threads are not "hung" in os::parK, they are parked - waiting > >> to be notified of something. > > > > It looks like the reference processing thread is stuck in a loop where > > it does wait(). So, the VM is hanging even if that stack trace also > > ends up in os::park(). > > > >> > >> The thing is to find out why they are not being woken up. > > > > Actually, in this case we should probably not even be calling wait... > > > >> > >> Can the gdb log be posted somewhere? I don't know if the attachment > >> made it to the original posting on hotspot-gc but it's no longer > >> available on hotspot-dev. > > > > I received the attachment with the original email. I've attached it to > > the bug report that I created: 8009536. You can find it there if you > > want to. But I think we have a fairly good idea of what change caused > > the hang. > > > > Bengt > > > >> > >> Thanks, > >> David > >> > >> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>> Hi Uwe, > >>> > >>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>> also work; that'll get you the Java stack trace. > >>> (But it probably doesn't matter in this case, because the hang is > >>> probably bug in the VM). > >>> > >>> - Kris > >>> > >>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >>> wrote: > >>>> Hi, > >>>> > >>>> since a few month we are extensively testing various preview builds > >>>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can > >>>> find any bugs early and prevent the problems we had with the > >>>> release of Java 7 two years ago. Currently we have a Linux (Ubuntu > >>>> 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 > >>>> snapshot, IBM J9, older JRockit) installed, choosing a different > >>>> one with different hotspot and garbage collector settings on every > >>>> run of the test suite (which takes approx. 30-45 minutes). > >>>> > >>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>> behavior in early versions (maybe compiler errors), but no longer > >>>> at the moment. There is one configuration that constantly and > >>>> reproducibly hangs in one module that is tested: The configuration > >>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > >>>> does not matter). The JVM running the tests hangs irresponsible > >>>> (jstack or kill -3 have no effect/cannot connect, standard kill > >>>> does not stop it, only kill -9 actually kills it). It can be > >>>> reproduced in this Lucene module 100% (it hangs always). > >>>> > >>>> I was able to connect with GDB to the JVM and get a stack trace on > >>>> all threads (see attachment, dump.txt). As you see all threads of > >>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in > >>>> pthread library). Unfortunately that?s all I can give you. A Java > >>>> stacktrace is not possible because the JVM reacts on neither kill > >>>> -3 nor jstack. With all other garbage collectors it passes the test > >>>> without hangs in a few seconds, with 32 bit G1GC it can stand still > >>>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit > >>>> variant is affected. Client or Server VM makes no difference. > >>>> > >>>> To reproduce: > >>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > >>>> should not matter) > >>>> - Download Lucene Source code (e.g. the snapshot version we were > >>>> testing with: > >>>> https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/ > >>>> lucene/dist/) > >>>> - change to directory lucene/analysis/uima and run: > >>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > >>>> -Dtests.jvms=1 test > >>>> After a while the test framework prints "stalled" messages (because > >>>> the child VM actually running the test no longer responds). The PID > >>>> is also printed. Try to get a stack trace or kill it, no response. > >>>> Only kill -9 helps. Choosing another garbage collector in the above > >>>> command line makes the test finish after a few seconds, e.g. > >>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>> > >>>> I posted this bug report directly to the mailing list, because with > >>>> earlier bug reports, there seem to be a problem with bugs.sun.com - > >>>> there is no response from any reviewer after several weeks and we > >>>> were able to help to find and fix javadoc and javac-compiler bugs > >>>> early. So I hope you can help for this bug, too. > >>>> > >>>> Uwe > >>>> > >>>> ----- > >>>> Uwe Schindler > >>>> uschindler at apache.org > >>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>> http://lucene.apache.org/ > >>>> > >>>> > > From Alan.Bateman at oracle.com Wed Mar 6 05:14:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 13:14:19 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5137412B.5080703@oracle.com> On 06/03/2013 04:13, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) Dean makes a good point, the @8 need be at the end to match the decoration scheme. Also I think it's 32-bit only although it should just not be found on 64-bit so it will skip on JNI_OnLoad_L. -Alan. From thomas.schatzl at oracle.com Wed Mar 6 05:43:04 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 14:43:04 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> Message-ID: <1362577384.2599.32.camel@cirrus> Hi, On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: > Hi Bengt, > > That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. > > Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. one possible reason is that the default mark stack size much is larger on 64 bit, so no mark stack overflow occurs. E.g. in globals.hpp: product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), \ You may want to try to set MarkStackSizeMax to 4M on 64 bit too to test this. This is just a hunch though. Thomas From Alan.Bateman at oracle.com Wed Mar 6 05:47:00 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 13:47:00 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <513748D4.3080803@oracle.com> On 05/03/2013 23:05, bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' > has been statically linked into the VM. If the symbol is found, it is > assumed that the library is linked in and will not be dynamically loaded. Overall I think this is quite good and follows the proposal in the JEP. I don't see anything obvious wrong with the logic and everything should just work for shared libraries as it does today. I assume you'll run all the appropriate tests. I see Dean's suggestion to add a JVM function to allow for a lookup table when the symbol information is available, If you do that then you'll need to get the hotspot changes in first. Alternatively, change what you have later once the hotspot changes are in.Just on the As findBuiltJniFunction can locate a built-in or a JNI_OnLoad/OnUnload in a library then the function name is probably not quite right (shouldn't have "Builtin" in the name). A minor nit in _findBuiltinLib is that if the OOME path should call JNU_ReleaseStringPlatformChars before returning. There are a few commented out statements in jni_util_md.c that I assume will be removed. Also you might want to check the indentation in both getProcessHandle implementations as they look like 2-spaces whereas the libs uses 4 (although this may be mute if you use a JVM function). Otherwise I think this is good and I can sponsor the jdk part to this and help get it into jdk8/tl. -Alan From kevin.walls at oracle.com Wed Mar 6 06:47:02 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 06 Mar 2013 14:47:02 +0000 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <513756E6.3060509@oracle.com> Vote: yes From kanakamohankumar at gmail.com Wed Mar 6 07:23:20 2013 From: kanakamohankumar at gmail.com (mohankumar kanaka) Date: Wed, 6 Mar 2013 20:53:20 +0530 Subject: PKCS11 support for 64bit Oracle java Message-ID: Hi, I am extremely sorry if it is wrong place, but i feel at least you can guide me Thanks in advance. This is Mohankumar working based in Hyderabad India working for MNC Recently i have worked on PKCS11 support for 64 bit Sun/oracle java i found the SUNPKCS11.jar and j2pkcs11.dll was missing due to which we are unable to initialize sunpkcs11 provider and initialize the keystore. So i have downloaded the sun dll source code and Java source code (and one JNI header file built by me from sunpkcs11.jar file) and i tried to build*j2pkcs11,dl *l on 64 bit environment and infact i was successful in building and tested with safenet cryptographic token it working absolutely fine But i do not know the where to submit the solution so that i would helpful for others. Have a great day!! Regards Mohankumar kanaka From staffan.larsen at oracle.com Wed Mar 6 07:24:00 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 6 Mar 2013 16:24:00 +0100 Subject: RFR(XS): 8009287 Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c In-Reply-To: <51367E6F.8030103@oracle.com> References: <5135A149.3040608@oracle.com> <51367B09.8030008@oracle.com> <51367E6F.8030103@oracle.com> Message-ID: <29AF58D4-F19B-4FFD-AE44-A2D3CCD921FB@oracle.com> On 6 mar 2013, at 00:23, David Holmes wrote: > On 6/03/2013 9:08 AM, Dean Long wrote: >> What if allocate_init_map() fails to allocate memory? Shouldn't >> add_class_share_map_info() follow the pattern of add_map_info(): >> return NULL or "map", and have the caller check for NULL? > > AFAICS apart from one seeming bug, if we can't allocate a new map it does no harm in terms of the code that looks at the map. The bug is: > > 177 mp = ph->core->class_share_maps; > 178 if (mp) { > 179 print_debug("can't locate map_info at 0x%lx, trying class share maps\n", > 180 addr); > > where I think 178 should be "if (mp==NULL)". I think this code is correct, although it took me a while to realize. If it can find a class share map, it reports that it will start looking at it. /Staffan > Everything else will just do nothing upon encountering a NULL map. > > The fix addresses the parfait warning and leaves the code functionally unchanged. So any robustness issues would need to be done via a follow up RFE. > > David > >> dl >> >> On 3/4/2013 11:39 PM, David Holmes wrote: >>> Looks fine to me - thanks Staffan! >>> >>> David >>> >>> On 5/03/2013 5:24 PM, Staffan Larsen wrote: >>>> A very small fix for a warning. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8009287/webrev.00/ >>>> >>>> Thanks, >>>> /Staffan >>>> >> From Alan.Bateman at oracle.com Wed Mar 6 08:13:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Mar 2013 16:13:33 +0000 Subject: PKCS11 support for 64bit Oracle java In-Reply-To: References: Message-ID: <51376B2D.7040101@oracle.com> On 06/03/2013 15:23, mohankumar kanaka wrote: > Hi, > > I am extremely sorry if it is wrong place, but i feel at least you > can guide me Thanks in advance. > > This is Mohankumar working based in Hyderabad India working for MNC > > Recently i have worked on PKCS11 support for 64 bit Sun/oracle java i found > the SUNPKCS11.jar and j2pkcs11.dll was missing due to which we are unable > to initialize sunpkcs11 provider and initialize the keystore. > > So i have downloaded the sun dll source code and Java source code (and one > JNI header file built by me from sunpkcs11.jar file) and i tried to > build*j2pkcs11,dl > *l on 64 bit environment and infact i was successful in building and tested > with safenet cryptographic token it working absolutely fine > > But i do not know the where to submit the solution so that i would helpful > for others. > > > Have a great day!! > Regards > Mohankumar kanaka I would suggest bringing this up on security-dev as that is the list where the PKCS11 provided is maintained. You might need to explain what you mean by "missing" as the PKCS11 provider isn't configured by default on all platforms (see list/preference order in lib/security/java.security). In any case, security-dev is the right place to discuss and propose a patch. -Alan. From bob.vandette at oracle.com Wed Mar 6 08:21:40 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 6 Mar 2013 11:21:40 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <51368F88.8000309@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> Message-ID: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on Windows, you can't just > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > "_JNI_OnLoad_" + + "@8" > Good catch Dean. > Looks like onLoadSymbols[] is unused in Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > Instead of adding getProcessHandle(), why not add JVM_FindBuiltinLibraryEntry() instead? > This would make it easier to support table-lookup when runtime symbol information is missing or not > supported by the platform. Bill has already factored out the implementation of getProcessHandle. Although your approach is cleaner, I'm concerned about creating a VM version dependency. For a traditional JRE that doesn't even require static library support, we'd have to make sure to run on a VM that support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of jni.h. If they didn't do that, we would have already gone down that path. The jdk sources already contain several instances of dlopen, dlysym and the Windows equivalents so I don't see a need to add a new VM function. Bob. > > dl > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. >> >> thanks, >> bill > From adomurad at redhat.com Wed Mar 6 09:45:36 2013 From: adomurad at redhat.com (Adam Domurad) Date: Wed, 06 Mar 2013 12:45:36 -0500 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <5130D0AB.8000001@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> <5130D0AB.8000001@oracle.com> Message-ID: <513780C0.9050103@redhat.com> On 03/01/2013 11:00 AM, Dmitry Samersoff wrote: > Adam, > > Thank you for advice! I'm looking for a possibility to remove > get_stack_bounds function entirely as Dean suggested. But it takes some > time. Hi again, not to be a bother, but do you have a rough time-frame that the fix will take? Thanks, -Adam From john.cuthbertson at oracle.com Wed Mar 6 10:04:16 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 10:04:16 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <1362577384.2599.32.camel@cirrus> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> Message-ID: <51378520.6060908@oracle.com> Hi Everyone, All: I've looked at the bug report (haven't tried to reproduce it yet) and Bengt's analysis is correct. The concurrent mark thread is entering the synchronization protocol in a marking step call. That code is waiting for some non-existent workers to terminate before proceeding. Normally we shouldn't be entering that code but I think we overflowed the global marking stack (I updated the CR at ~1am my time with that conjecture). I think I missed a set_phase() call to tell the parallel terminator that we only have one thread and it's picking up the number of workers that executed the remark parallel task. Thomas: you were on the right track with your comment about the marking stack size. David: Thanks for helping out here. The stack trace you mentioned was for one the refinement threads - a concurrent GC thread. When a concurrent GC thread "joins" the suspendible thread set, it means that it will observe and participate in safepoint operations, i.e. the thread will notice that it should reach a safepoint and the safepoint synchronizer code will wait for it to block. When we wish a concurrent GC thread to not observe safepoints, that thread leaves the suspendible thread set. I think the name could be a bit better and Tony, before he left, had a change that used a scoped object to join and leave the STS that hasn't been integrated yet. IIRC Tony wasn't happy with the name he chose for that also. Uwe: Thanks for bringing this up and my apologies for not replying sooner. I will have a fix fairly soon. If I'm correct about it being caused by overflowing the marking stack you can work around the issue by increasing the MarkStackSize.you could try increasing it to 2M or 4M entries (which is the current max size). Cheers, JohnC On 3/6/2013 5:43 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: >> Hi Bengt, >> >> That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. >> >> Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. > one possible reason is that the default mark stack size much is larger > on 64 bit, so no mark stack overflow occurs. > > E.g. in globals.hpp: > > product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), > \ > > You may want to try to set MarkStackSizeMax to 4M on 64 bit too to test > this. > > This is just a hunch though. > > Thomas > > From uschindler at apache.org Wed Mar 6 10:50:35 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 19:50:35 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51378520.6060908@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> Message-ID: <006201ce1a9b$7ccb14a0$76613de0$@apache.org> Hi John, Thanks for the response and the analysis, very informative! > Hi Everyone, > > All: > I've looked at the bug report (haven't tried to reproduce it yet) and Bengt's > analysis is correct. The concurrent mark thread is entering the > synchronization protocol in a marking step call. That code is waiting for some > non-existent workers to terminate before proceeding. Normally we > shouldn't be entering that code but I think we overflowed the global marking > stack (I updated the CR at ~1am my time with that conjecture). I think I > missed a set_phase() call to tell the parallel terminator that we only have one > thread and it's picking up the number of workers that executed the remark > parallel task. > > Thomas: you were on the right track with your comment about the marking > stack size. > > David: > Thanks for helping out here. The stack trace you mentioned was for one the > refinement threads - a concurrent GC thread. When a concurrent GC thread > "joins" the suspendible thread set, it means that it will observe and > participate in safepoint operations, i.e. the thread will notice that it should > reach a safepoint and the safepoint synchronizer code will wait for it to block. > When we wish a concurrent GC thread to not observe safepoints, that > thread leaves the suspendible thread set. I think the name could be a bit > better and Tony, before he left, had a change that used a scoped object to > join and leave the STS that hasn't been integrated yet. IIRC Tony wasn't > happy with the name he chose for that also. > > Uwe: > Thanks for bringing this up and my apologies for not replying sooner. I will > have a fix fairly soon. If I'm correct about it being caused by overflowing the > marking stack you can work around the issue by increasing the > MarkStackSize.you could try increasing it to 2M or 4M entries (which is the > current max size). Is there a setting on the command line to raise this size? This would be great to check out if one can also do the opposite (lower the size on 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I am not so familiar with building the JVM on Ubuntu machines (including the needed IcedTea), so it's hard to me to try this out - I would not even know how to start doing this or finally how to get something like a standard JDK directory so you could use it as JAVA_HOME. If you need a verification that your patch is working, it would be good to get a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins server that found the bug. Otherwise we would need to wait until a new build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac tool and the class library that we reported earlier). I could also assist in setting up a Lucene build directory (as reported on the first email), to reproduce the problem with the Lucene source code (which is very easy). As said before, I have no isolated test case :( Thanks in any case, Uwe > Cheers, > > JohnC > > On 3/6/2013 5:43 AM, Thomas Schatzl wrote: > > Hi, > > > > On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: > >> Hi Bengt, > >> > >> That was fast! We are happy that you were able to analyze the bug and > will fix it soon. To not make our Jenkins server get stuck in the tests, I will > disable G1GC until a new update is installed. We will then only test the other > garbage collectors with Lucene. > >> > >> Do you have an idea, why this bug is not appearing on 64 bit? It might be > caused by other GC behavior as the word size is different (the Lucene tests > use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to > understand this! I can run the test suite with 64 bit JDK over and over, it > never hangs. But when running with 32 bit it hangs in all cases. > > one possible reason is that the default mark stack size much is > > larger on 64 bit, so no mark stack overflow occurs. > > > > E.g. in globals.hpp: > > > > product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), > \ > > > > You may want to try to set MarkStackSizeMax to 4M on 64 bit too to > > test this. > > > > This is just a hunch though. > > > > Thomas > > > > From john.cuthbertson at oracle.com Wed Mar 6 10:56:06 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 10:56:06 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006201ce1a9b$7ccb14a0$76613de0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> Message-ID: <51379146.4040106@oracle.com> Hi Uwe, You must have been reading my mind. See inline.... On 3/6/2013 10:50 AM, Uwe Schindler wrote: > Hi John, > > Thanks for the response and the analysis, very informative! > >> Uwe: >> Thanks for bringing this up and my apologies for not replying sooner. I will >> have a fix fairly soon. If I'm correct about it being caused by overflowing the >> marking stack you can work around the issue by increasing the >> MarkStackSize.you could try increasing it to 2M or 4M entries (which is the >> current max size). > Is there a setting on the command line to raise this size? This would be great to check out if one can also do the opposite (lower the size on 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I am not so familiar with building the JVM on Ubuntu machines (including the needed IcedTea), so it's hard to me to try this out - I would not even know how to start doing this or finally how to get something like a standard JDK directory so you could use it as JAVA_HOME. Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. > If you need a verification that your patch is working, it would be good to get a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins server that found the bug. Otherwise we would need to wait until a new build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac tool and the class library that we reported earlier). > > I could also assist in setting up a Lucene build directory (as reported on the first email), to reproduce the problem with the Lucene source code (which is very easy). As said before, I have no isolated test case :( > I just sent you email. I downloaded a zip file that contains all the jar files. I don't have ant on my system so ideally I'm looking for a java command line to tickle the crash. Can you help? Thanks, JohnC From uschindler at apache.org Wed Mar 6 11:17:50 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:17:50 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379146.4040106@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> Message-ID: <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> Hi, > Hi Uwe, > > You must have been reading my mind. See inline.... > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > Hi John, > > > > Thanks for the response and the analysis, very informative! > > > >> Uwe: > >> Thanks for bringing this up and my apologies for not replying sooner. > >> I will have a fix fairly soon. If I'm correct about it being caused > >> by overflowing the marking stack you can work around the issue by > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > >> entries (which is the current max size). > > Is there a setting on the command line to raise this size? This would be > great to check out if one can also do the opposite (lower the size on 64 bit > JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I > am not so familiar with building the JVM on Ubuntu machines (including the > needed IcedTea), so it's hard to me to try this out - I would not even know > how to start doing this or finally how to get something like a standard JDK > directory so you could use it as JAVA_HOME. > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. I will give it a quick try! > > If you need a verification that your patch is working, it would be good to get > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > server that found the bug. Otherwise we would need to wait until a new > build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac > tool and the class library that we reported earlier). > > > > I could also assist in setting up a Lucene build directory (as > > reported on the first email), to reproduce the problem with the Lucene > > source code (which is very easy). As said before, I have no isolated > > test case :( > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > don't have ant on my system so ideally I'm looking for a java command line to > tickle the crash. Can you help? I responded. Unfortunately, the binary Lucene distribution does not contain the tests.... I will try to set something up and share via a download link from my dropbox. > Thanks, > > JohnC ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 7:56 PM > To: Uwe Schindler > Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; > 'Dawid Weiss'; hotspot-dev at openjdk.java.net > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > You must have been reading my mind. See inline.... > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > Hi John, > > > > Thanks for the response and the analysis, very informative! > > > >> Uwe: > >> Thanks for bringing this up and my apologies for not replying sooner. > >> I will have a fix fairly soon. If I'm correct about it being caused > >> by overflowing the marking stack you can work around the issue by > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > >> entries (which is the current max size). > > Is there a setting on the command line to raise this size? This would be > great to check out if one can also do the opposite (lower the size on 64 bit > JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I > am not so familiar with building the JVM on Ubuntu machines (including the > needed IcedTea), so it's hard to me to try this out - I would not even know > how to start doing this or finally how to get something like a standard JDK > directory so you could use it as JAVA_HOME. > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. > > > If you need a verification that your patch is working, it would be good to get > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > server that found the bug. Otherwise we would need to wait until a new > build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac > tool and the class library that we reported earlier). > > > > I could also assist in setting up a Lucene build directory (as > > reported on the first email), to reproduce the problem with the Lucene > > source code (which is very easy). As said before, I have no isolated > > test case :( > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > don't have ant on my system so ideally I'm looking for a java command line to > tickle the crash. Can you help? > > Thanks, > > JohnC From uschindler at apache.org Wed Mar 6 11:31:56 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:31:56 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> Message-ID: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Hi, > > >> Uwe: > > >> Thanks for bringing this up and my apologies for not replying sooner. > > >> I will have a fix fairly soon. If I'm correct about it being caused > > >> by overflowing the marking stack you can work around the issue by > > >> increasing the MarkStackSize.you could try increasing it to 2M or > > >> 4M entries (which is the current max size). > > > Is there a setting on the command line to raise this size? This > > > would be > > great to check out if one can also do the opposite (lower the size on > > 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java > > programmer I am not so familiar with building the JVM on Ubuntu > > machines (including the needed IcedTea), so it's hard to me to try > > this out - I would not even know how to start doing this or finally > > how to get something like a standard JDK directory so you could use it as > JAVA_HOME. > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > run. > > I will give it a quick try! 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? Uwe > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > -----Original Message----- > > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > > Sent: Wednesday, March 06, 2013 7:56 PM > > To: Uwe Schindler > > Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; > > 'Dawid Weiss'; hotspot-dev at openjdk.java.net > > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > bit) > > > > Hi Uwe, > > > > You must have been reading my mind. See inline.... > > > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > > Hi John, > > > > > > Thanks for the response and the analysis, very informative! > > > > > >> Uwe: > > >> Thanks for bringing this up and my apologies for not replying sooner. > > >> I will have a fix fairly soon. If I'm correct about it being caused > > >> by overflowing the marking stack you can work around the issue by > > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > > >> entries (which is the current max size). > > > Is there a setting on the command line to raise this size? This would be > > great to check out if one can also do the opposite (lower the size on 64 bit > > JVM to make the 64 bit one also hang). Unfortunately as a Java > programmer I > > am not so familiar with building the JVM on Ubuntu machines (including the > > needed IcedTea), so it's hard to me to try this out - I would not even know > > how to start doing this or finally how to get something like a standard JDK > > directory so you could use it as JAVA_HOME. > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > run. > > > > > If you need a verification that your patch is working, it would be good to > get > > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > > server that found the bug. Otherwise we would need to wait until a new > > build appears on jdk8.java.net (including the fix + other fixes in > javadoc/javac > > tool and the class library that we reported earlier). > > > > > > I could also assist in setting up a Lucene build directory (as > > > reported on the first email), to reproduce the problem with the Lucene > > > source code (which is very easy). As said before, I have no isolated > > > test case :( > > > > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > > don't have ant on my system so ideally I'm looking for a java command line > to > > tickle the crash. Can you help? > > > > Thanks, > > > > JohnC From thomas.schatzl at oracle.com Wed Mar 6 11:44:27 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 20:44:27 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Message-ID: <1362599067.2938.13.camel@cirrus> Hi, On Wed, 2013-03-06 at 20:31 +0100, Uwe Schindler wrote: > Hi, > > > >> Uwe: > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > > run. > > > > I will give it a quick try! > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. > Maybe you have to set -XX:MaxMarkStackSize as well, but it does not matter now I guess. > To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? > Use -XX:+PrintFlagsFinal on the 32 bit VM to get this value. The flag prints a list of all effective flag values after option processing. Hth, Thomas From john.cuthbertson at oracle.com Wed Mar 6 12:02:36 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 12:02:36 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Message-ID: <5137A0DC.5050209@oracle.com> Hi Uwe, The default mark stack size for 32 bit is 32K entries. So try -XX:MarkStackSize=32K. This might not overflow because the local marking task queues are larger in the 64 bit JVM so there will be less pressure on the global mark stack. Unfortunately the task queue size is a constant (actually a template constant either 16K for 32 bit and 128K for 64 bit). You might have to go lower. JohnC On 03/06/13 11:31, Uwe Schindler wrote: > Hi, > > >>>>> Uwe: >>>>> Thanks for bringing this up and my apologies for not replying sooner. >>>>> I will have a fix fairly soon. If I'm correct about it being caused >>>>> by overflowing the marking stack you can work around the issue by >>>>> increasing the MarkStackSize.you could try increasing it to 2M or >>>>> 4M entries (which is the current max size). >>>>> >>>> Is there a setting on the command line to raise this size? This >>>> would be >>>> >>> great to check out if one can also do the opposite (lower the size on >>> 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java >>> programmer I am not so familiar with building the JVM on Ubuntu >>> machines (including the needed IcedTea), so it's hard to me to try >>> this out - I would not even know how to start doing this or finally >>> how to get something like a standard JDK directory so you could use it as >>> >> JAVA_HOME. >> >>> Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit >>> >> run. >> >> I will give it a quick try! >> > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. > > To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? > > Uwe > > >> ----- >> Uwe Schindler >> uschindler at apache.org >> Apache Lucene PMC Member / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >> >> >>> -----Original Message----- >>> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >>> Sent: Wednesday, March 06, 2013 7:56 PM >>> To: Uwe Schindler >>> Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; >>> 'Dawid Weiss'; hotspot-dev at openjdk.java.net >>> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 >>> >> bit) >> >>> Hi Uwe, >>> >>> You must have been reading my mind. See inline.... >>> >>> On 3/6/2013 10:50 AM, Uwe Schindler wrote: >>> >>>> Hi John, >>>> >>>> Thanks for the response and the analysis, very informative! >>>> >>>> >>>>> Uwe: >>>>> Thanks for bringing this up and my apologies for not replying sooner. >>>>> I will have a fix fairly soon. If I'm correct about it being caused >>>>> by overflowing the marking stack you can work around the issue by >>>>> increasing the MarkStackSize.you could try increasing it to 2M or 4M >>>>> entries (which is the current max size). >>>>> >>>> Is there a setting on the command line to raise this size? This would be >>>> >>> great to check out if one can also do the opposite (lower the size on 64 bit >>> JVM to make the 64 bit one also hang). Unfortunately as a Java >>> >> programmer I >> >>> am not so familiar with building the JVM on Ubuntu machines (including the >>> needed IcedTea), so it's hard to me to try this out - I would not even know >>> how to start doing this or finally how to get something like a standard JDK >>> directory so you could use it as JAVA_HOME. >>> >>> Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit >>> >> run. >> >>>> If you need a verification that your patch is working, it would be good to >>>> >> get >> >>> a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins >>> server that found the bug. Otherwise we would need to wait until a new >>> build appears on jdk8.java.net (including the fix + other fixes in >>> >> javadoc/javac >> >>> tool and the class library that we reported earlier). >>> >>>> I could also assist in setting up a Lucene build directory (as >>>> reported on the first email), to reproduce the problem with the Lucene >>>> source code (which is very easy). As said before, I have no isolated >>>> test case :( >>>> >>>> >>> I just sent you email. I downloaded a zip file that contains all the jar files. I >>> don't have ant on my system so ideally I'm looking for a java command line >>> >> to >> >>> tickle the crash. Can you help? >>> >>> Thanks, >>> >>> JohnC >>> > > From uschindler at apache.org Wed Mar 6 12:10:34 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 21:10:34 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <1362599067.2938.13.camel@cirrus> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> <1362599067.2938.13.camel@cirrus> Message-ID: <007e01ce1aa6$a93fd830$fbbf8890$@apache.org> > Hi, > > On Wed, 2013-03-06 at 20:31 +0100, Uwe Schindler wrote: > > Hi, > > > > >> Uwe: > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a > > > > 32 bit > > > run. > > > > > > I will give it a quick try! > > > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. > With that setting the tests went through as they should (in 22 secs on this > server). With the default setting it stalled endless. > > > > Maybe you have to set -XX:MaxMarkStackSize as well, but it does not matter > now I guess. > > > To test the inverse (make 64 bit hang): What's the default stack size of 32 > bit JVMs, so I can set it on 64 bit to make it hang? > > > > Use -XX:+PrintFlagsFinal on the 32 bit VM to get this value. The flag prints a > list of all effective flag values after option processing. Thanks. Unfortunately I did not get the 64 bit JVM to hang, not even with 1K stack size. It could be because Lucene or the used UIMA library in this test uses other defaults and behaves different GC-wise, or - as John mentioned - the task queue size is different. I was able to check some values in 32bit: with the default stack size of 32K it hangs, with 64K the same, 92K also hangs. But 128K passes and works with this test. Uwe From uschindler at apache.org Wed Mar 6 12:16:56 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 21:16:56 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379703.5080203@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <51379703.5080203@oracle.com> Message-ID: <008201ce1aa7$8ceb6220$a6c22660$@apache.org> Hi again, If you don't get it running, I can do the following: I may set it up in /tmp locally. Then build and test the whole Lucene library including test. I could then TAR it up (might be large approx. 100 MB) and send it to you via dropbox or any other HTTP download. The command line of the JVM uses absolute paths for all JARs and other settings, but if you unpack the whole thing to /tmp, you could reuse the cmd line. Just tell me, if you were able to set it up, otherwise I can quickly TAR you the whole compiled directory and give you the command line from debugging output. If you unpack to another directory you might need to edit the command line with its absolute paths (which are generated by ANT). Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 8:21 PM > To: Uwe Schindler > Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > Let me try with your detailed instructions below before you go to all of that > trouble. I will let you know how I get on. > > Thanks, > > JohnC > > On 3/6/2013 11:15 AM, Uwe Schindler wrote: > > Hi, > > > > That's unfortunately not so easy, because of project dependencies. To run > the test you have to compile Lucene Core then the specific module + the test > framework (which is special for Lucene) and download some JARs from > Maven central (JAR hell, as usual). > > If you give me some time, I would collect all needed JAR files from my local > checkout and provide you the correct cmd line + a ZIP file with maybe a shell > script to startup. It should be doable, but needs some work to collect all > dependencies for the classpath. > > > > If you want to do it quicker (should be quite fast to do): > > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making > it not working out of the box with Java 8): > http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I > just wonder about the fact: isn't ANT needed to build the JDK classlib by > itself? I remember that the FreeBSD OpenJDK build downloads ANT and does > a large part of the compilation using ANT... > > - put the ANT bin/ dir into your PATH > > - download the Apache Lucene source code from Jenkins: > > https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/luc > > ene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this > > will download Apache IVY, so all dependencies can be downloaded from > > Maven Central) > > - change to the module that fails: # cd analysis/uima > > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test > > - In a parallel console you might be able to attach to the process, the build > in the main console using ANT runs inside ANT and the test framework > spawns separate worker instances of the JVM to execute the tests. This > makes it hard to reproduce in standalone (the command line passed to the > child JVM is veeeeery long). > > > > I will work on putting together a precompiled ZIP file with all needed JARs + > the command line. Just tell me if you got it managed with the above howto, > then I don?t need to do this. > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > > >> -----Original Message----- > >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > >> Sent: Wednesday, March 06, 2013 7:51 PM > >> To: Uwe Schindler > >> Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > >> dev at lucene.apache.org > >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > >> bit) > >> > >> Hi Uwe, > >> > >> I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > >> https://builds.apache.org/job/Lucene-Artifacts- > >> trunk/2212/artifact/lucene/dist/ > >> > >> I don't have ant on my workstation so do you have a java command line > >> to run the test(s) that generate the error? > >> > >> Thanks, > >> > >> JohnC > >> > >> On 3/6/2013 3:16 AM, Uwe Schindler wrote: > >>> Hi, > >>> > >>>> I think this is a VM bug and the thread dumps that Uwe produced are > >>>> enough to start tracking down the root cause. > >>> I hope it is enough! If I can help with more details, tell me what I > >>> should do > >> to track this down. Unfortunately, we have no isolated test case > >> (like a small java class that triggers this bug) - you have to run > >> the test cases of this Lucene's module. It only happens there, not in > >> any other Lucene test suite. It may be caused by a lot of GC activity in this > "UIMA" module or a specific test. > >>>> On 3/6/13 8:52 AM, David Holmes wrote: > >>>>> If the VM is completely unresponsive then it suggests we are at a > >>>>> safepoint. > >>>> Yes, we are hanging during a stop-the-world GC, so we are at a > safepoint. > >>>> > >>>>> The GC threads are not "hung" in os::parK, they are parked - > >>>>> waiting to be notified of something. > >>>> It looks like the reference processing thread is stuck in a loop > >>>> where it does wait(). So, the VM is hanging even if that stack > >>>> trace also ends up in os::park(). > >>>> > >>>>> The thing is to find out why they are not being woken up. > >>>> Actually, in this case we should probably not even be calling wait... > >>>> > >>>>> Can the gdb log be posted somewhere? I don't know if the > >>>>> attachment made it to the original posting on hotspot-gc but it's > >>>>> no longer available on hotspot-dev. > >>>> I received the attachment with the original email. I've attached it > >>>> to the bug report that I created: 8009536. You can find it there if > >>>> you want to. But I think we have a fairly good idea of what change > >>>> caused the hang. > >>> If it helps: Unfortunately, we had some problems with recent JDK > >>> builds, > >> because javac and javadoc tools were not working correctly, failing > >> to build our source code. Since b78 this was fixed. Until this was > >> fixed, we used build > >> b65 (which was the last one working) and the G1GC hangs did not > >> appear on this version. So it must have happened by a change after b65 till > b78. > >>> Uwe > >>> > >>>> Bengt > >>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>>>>> Hi Uwe, > >>>>>> > >>>>>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>>>>> also work; that'll get you the Java stack trace. > >>>>>> (But it probably doesn't matter in this case, because the hang is > >>>>>> probably bug in the VM). > >>>>>> > >>>>>> - Kris > >>>>>> > >>>>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >>>> > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> since a few month we are extensively testing various preview > >>>>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, > >>>>>>> so we can find any bugs early and prevent the problems we had > >>>>>>> with the release of Java 7 two years ago. Currently we have a > >>>>>>> Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK > >>>>>>> 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, > >>>>>>> choosing a different one with different hotspot and garbage > >>>>>>> collector settings on every run of the test suite (which takes > >>>>>>> approx. 30-45 > >> minutes). > >>>>>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>>>>> behavior in early versions (maybe compiler errors), but no > >>>>>>> longer at the moment. There is one configuration that constantly > >>>>>>> and reproducibly hangs in one module that is tested: The > >>>>>>> configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC > >>>>>>> (server or client does not matter). The JVM running the tests > >>>>>>> hangs irresponsible (jstack or kill -3 have no effect/cannot > >>>>>>> connect, standard kill does not stop it, only kill -9 actually > >>>>>>> kills it). It can be reproduced in this Lucene module 100% (it hangs > always). > >>>>>>> > >>>>>>> I was able to connect with GDB to the JVM and get a stack trace > >>>>>>> on all threads (see attachment, dump.txt). As you see all > >>>>>>> threads of G1GC seem to hang in a syscall (os:park(), a > >>>>>>> conditional wait in pthread library). Unfortunately that?s all I > >>>>>>> can give you. A Java stacktrace is not possible because the JVM > >>>>>>> reacts on neither kill > >>>>>>> -3 nor jstack. With all other garbage collectors it passes the > >>>>>>> test without hangs in a few seconds, with 32 bit G1GC it can > >>>>>>> stand still for hours. The 64 bit JVM passes with G1GC, so only > >>>>>>> the 32 bit variant is affected. Client or Server VM makes no > difference. > >>>>>>> > >>>>>>> To reproduce: > >>>>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but > >>>>>>> this should not matter) > >>>>>>> - Download Lucene Source code (e.g. the snapshot version we > were > >>>>>>> testing with: > >>>>>>> https://builds.apache.org/job/Lucene-Artifacts- > >>>> trunk/2212/artifact/lucene/dist/) > >>>>>>> - change to directory lucene/analysis/uima and run: > >>>>>>> ant -Dargs="-server -XX:+UseG1GC" > >>>>>>> -Dtests.multiplier=3 > >>>>>>> -Dtests.jvms=1 test > >>>>>>> After a while the test framework prints "stalled" messages > >>>>>>> (because the child VM actually running the test no longer > >>>>>>> responds). The PID is also printed. Try to get a stack trace or > >>>>>>> kill it, no > >> response. > >>>>>>> Only kill -9 helps. Choosing another garbage collector in the > >>>>>>> above command line makes the test finish after a few seconds, e.g. > >>>>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>>>>> > >>>>>>> I posted this bug report directly to the mailing list, because > >>>>>>> with earlier bug reports, there seem to be a problem with > >>>>>>> bugs.sun.com - there is no response from any reviewer after > >>>>>>> several weeks and we were able to help to find and fix javadoc > >>>>>>> and javac-compiler bugs early. So I hope you can help for this bug, > too. > >>>>>>> > >>>>>>> Uwe > >>>>>>> > >>>>>>> ----- > >>>>>>> Uwe Schindler > >>>>>>> uschindler at apache.org > >>>>>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>>>>> http://lucene.apache.org/ > >>>>>>> > >>>>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org For additional > commands, e-mail: dev-help at lucene.apache.org From bill.pittore at oracle.com Wed Mar 6 12:43:10 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 06 Mar 2013 15:43:10 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5136C26B.7000805@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <5136C26B.7000805@oracle.com> Message-ID: <5137AA5E.2070602@oracle.com> Actually for windows I *did* export the undecorated name. I just didn't see where I did it in the VS IDE. If you don't export the undecorated name it doesn't work of course. bill On 3/5/2013 11:13 PM, BILL PITTORE wrote: > On 3/5/2013 7:36 PM, Dean Long wrote: >> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on >> Windows, you can't just >> turn that into "_JNI_OnLoad at 8_" + . I think it needs to be >> "_JNI_OnLoad_" + + "@8" > I'll look into that. When I built for windows and ran our test, the > JNI_OnLoad_TestStaticLib was exported without the decoration just > based on the JNIEXPORT JNICALL specifiers on the function. I didn't do > anything special to export it. But I recall this problem from another > project. > 1 0 00001014 JNI_OnLoad_TestStaticLib = > @ILT+15(?JNI_OnLoad_TestStaticLib@@YGHPAUJavaVM_@@PAX at Z) >> >> Looks like onLoadSymbols[] is unused in >> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > I'll remove that. I redid the call to findBuiltinJniFunction but > forgot to remove that. > >> >> Instead of adding getProcessHandle(), why not add >> JVM_FindBuiltinLibraryEntry() instead? >> This would make it easier to support table-lookup when runtime symbol >> information is missing or not >> supported by the platform. > Not sure I'm following you on this. Make JVM_FindBuiltinLibraryEntry() > an exported function in the VM? How does it find JNI_OnLoad_L? Via a > table setup by the developer/build system when the library is linked in? > > bill > >> >> dl >> >> On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: >>> This request is tied to bugid 8005716 that deals with adding support >>> for statically linked JNI libraries. >>> >>> The JEP is here: http://openjdk.java.net/jeps/178 >>> >>> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >>> >>> The webrevs are here: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >>> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >>> >>> The main piece of functionality is to check for the presence of >>> JNI_OnLoad_libname to determine if the library specified by >>> 'libname' has been statically linked into the VM. If the symbol is >>> found, it is assumed that the library is linked in and will not be >>> dynamically loaded. >>> >>> thanks, >>> bill >> > From coleen.phillimore at oracle.com Wed Mar 6 13:25:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Mar 2013 16:25:02 -0500 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <5136D38C.9040100@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> <5136D38C.9040100@oracle.com> Message-ID: <5137B42E.7090704@oracle.com> Jon, Thank you for reviewing this change. On 03/06/2013 12:26 AM, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html > > > *- ConstantPoolCache* ConstantPoolCache::allocate(ClassLoaderData* > loader_data, int length, TRAPS) {* > *+ int length,* > *+ const intStack& index_map,* > *+ const intStack& > invokedynamic_map, TRAPS) { > * > > Why did you not move the TRAP parameter to a new line? > I think TRAPS aren't interesting enough and short enough not to merit their own line. > http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html > > > Did you remove the TieredCompilation test > > *if (TieredCompilation) { > * > > for consistency of initialization? Yes, I did. I don't know if people will object but I think it's more sanitary to have these zero initialized even if they are not used in !TieredCompilation. And I had a consistency check that I took out that flagged these. > > > http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html > > > * #ifndef PRODUCT* > * int _verify_count; // to avoid redundant verifies* > * #endif* > > Not concerned about redundant verifies anymore? > I moved it from Klass* to InstanceKlass* where it's used. It still protects us from redundant verifies. > Rest looks good. > Thanks! Coleen > Jon > > > On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >> >> Adding hotspot-dev to get some more potential reviewers from maybe >> the GC team, hint... >> >> Coleen >> >> On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >>> Summary: Zero metadata in constructors, not in allocation (and some >>> in constructors) >>> >>> This seems like a good first step in passing initial values into >>> constructors and no initializing metadata types by the callers >>> (although a lot more parameters will have to be passed for some). >>> >>> Tested with runThese jck, NSK vm.quick.testlist, lang and vm jck8, >>> java/lang/annotation jtreg tests and java/lang/invoke jtreg tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >>> >>> Thanks, >>> Coleen >>> >>> >> > From GARY.COLLINS at ORACLE.COM Wed Mar 6 16:43:08 2013 From: GARY.COLLINS at ORACLE.COM (Gary Collins) Date: Wed, 6 Mar 2013 16:43:08 -0800 Subject: RFR: JDK-8009152 - A number of jtreg tests need review/improvement Message-ID: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> Request for Review Changes to allow better test utilization of jtreg hotspot regression tests 1: REPLACED JAVA_HOME with TESTJAVA 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) 3: Replaced most of the BIT_FLAG with TESTVMOPTS NOTE: This allows the tests where possible to run with multiple compilers and switches. Asked for by Quality team 4: Added TESTJAVACOPTS for all javac compile lines. Suggestion from tools folks. 5: Added a new shell env template. Phase 2 of hotspot test cleanup will utilize this file NOTE: This test_env.sh file will allow engineers to remove allot of the copy/paste of test setup from each shell testcase. 6: Fixed a gc testcase that was timing out on a 24 core box.. Simple fix , add a timeout. 7: I filed many bugs around native case issues. This changeset it not to address broken tests. Only to conform them in a unified way of running. 8: Fixing tests as defined above allows us to run the tests from a JRE. embedded use cases this is a stop gap. 9: In order to run jtreg with a JRE you need to define TESTJAVA (JRE - jdk/testjdk) & COMPILEJAVA (JDK - compilejdk) If TESTJAVA is a JDK no need to set COMPILEJAVA. NOTE: Most shell scripts from the command line may fail with the following issues: TESTSRC not defined, TESTCLASSES not defined, COMPILEJAVA path not found because we don't check for them at runtime. #5 above will fix this in the next phase of improving these tests to be more robust. Fully tested on linux-i586 builds with server/client jvm. Webrev: http://cr.openjdk.java.net/~collins/8009152/webrev-rev0/ Please let me know if you have any suggestions. Thanks Gary From vladimir.kozlov at oracle.com Wed Mar 6 17:59:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Mar 2013 17:59:53 -0800 Subject: RFR: JDK-8009152 - A number of jtreg tests need review/improvement In-Reply-To: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> Message-ID: <5137F499.3030908@oracle.com> test_env.sh should have Copyright header since it in open. Also there is duplicated java -version commands. I think first one at line 12 should be removed and the check (lines 14-18) moved after second one at line 77. Changes in tests scripts are fine. Thanks, Vladimir On 3/6/13 4:43 PM, Gary Collins wrote: > Request for Review > > Changes to allow better test utilization of jtreg hotspot regression tests > 1: REPLACED JAVA_HOME with TESTJAVA > 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. > NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. > NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) > 3: Replaced most of the BIT_FLAG with TESTVMOPTS > NOTE: This allows the tests where possible to run with multiple compilers and switches. Asked for by Quality team > 4: Added TESTJAVACOPTS for all javac compile lines. Suggestion from tools folks. > 5: Added a new shell env template. Phase 2 of hotspot test cleanup will utilize this file > NOTE: This test_env.sh file will allow engineers to remove allot of the copy/paste of test setup from each shell testcase. > 6: Fixed a gc testcase that was timing out on a 24 core box.. Simple fix , add a timeout. > 7: I filed many bugs around native case issues. This changeset it not to address broken tests. Only to conform them in > a unified way of running. > 8: Fixing tests as defined above allows us to run the tests from a JRE. embedded use cases this is a stop gap. > 9: In order to run jtreg with a JRE you need to define TESTJAVA (JRE - jdk/testjdk) & COMPILEJAVA (JDK - compilejdk) > If TESTJAVA is a JDK no need to set COMPILEJAVA. > NOTE: Most shell scripts from the command line may fail with the following issues: > TESTSRC not defined, TESTCLASSES not defined, COMPILEJAVA path not found because we don't > check for them at runtime. #5 above will fix this in the next phase of improving these tests to be more > robust. > > Fully tested on linux-i586 builds with server/client jvm. > > Webrev: > http://cr.openjdk.java.net/~collins/8009152/webrev-rev0/ > > Please let me know if you have any suggestions. > Thanks > Gary > > > From bill.pittore at oracle.com Wed Mar 6 18:51:57 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 06 Mar 2013 21:51:57 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> References: <51367A43.1060606@oracle.com> <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> Message-ID: <513800CD.6000502@oracle.com> On 3/6/2013 12:50 PM, Mike Duigou wrote: > Hi Bill; > > Some notes from reviewing the JDK side changes. > > > System.java/Runtime.java: > > The example which begins with the name "If the filename argument, " needs to better identify that "L" is an example. (Italics?) Re-worded that a bit. > java/lang/ClassLoader.java: > > NativeLibrary::fromClass could be final. Ok. > > ClassLoader.c: > > In Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib() > > These two values are known at compile time. > > int prefixLen = (int) strlen(JNI_LIB_PREFIX); > int suffixLen = (int) strlen(JNI_LIB_SUFFIX); > > Some of the error conditions don't throw exceptions. Such as: > > if (cname == NULL) { > return NULL; > } Fixed. > The prefix and suffix are stripped from cname without checking that cname actually contains the prefix or suffix. ..._findBuiltinLib is only called after System.mapLibraryName has added prefix and suffix. > > if (len > prefixLen) is invariant. Based on System.mapLibraryName always called, then this could just be an assert. Unless JNU_GetStringPlatformChars returns some bogus string. > > src/solaris/native/common/jni_util_md.c: > > void* getProcessHandle() { > static void* procHandle = NULL; > if (procHandle == NULL) { > procHandle = (void*)dlopen(NULL, RTLD_LAZY); > } > > return procHandle; > } > > Why is the error handling code commented out? That was just for some debugging. I've removed it. Thanks for commenting. I'll get a new webrev up shortly. bill > > Mike > > > On Mar 5 2013, at 15:05 , bill.pittore at oracle.com wrote: > >> This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. >> >> thanks, >> bill From gary.collins at oracle.com Wed Mar 6 19:06:46 2013 From: gary.collins at oracle.com (Gary Collins) Date: Wed, 6 Mar 2013 19:06:46 -0800 Subject: RFR: JDK-8009152 - A number of jtreg tests need review/improvement In-Reply-To: <5137F499.3030908@oracle.com> References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> <5137F499.3030908@oracle.com> Message-ID: <467A6A7D-EBB7-49AF-8616-A9CCD9DCBBF5@oracle.com> Thanks.. Will do. Good suggestion.. Missed the copyright. Will fix that. Sent from my iPad On Mar 6, 2013, at 5:59 PM, Vladimir Kozlov wrote: > test_env.sh should have Copyright header since it in open. Also there is duplicated java -version commands. I think first one at line 12 should be removed and the check (lines 14-18) moved after second one at line 77. > > Changes in tests scripts are fine. > > Thanks, > Vladimir > > On 3/6/13 4:43 PM, Gary Collins wrote: >> Request for Review >> >> Changes to allow better test utilization of jtreg hotspot regression tests >> 1: REPLACED JAVA_HOME with TESTJAVA >> 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. >> NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. >> NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) >> 3: Replaced most of the BIT_FLAG with TESTVMOPTS >> NOTE: This allows the tests where possible to run with multiple compilers and switches. Asked for by Quality team >> 4: Added TESTJAVACOPTS for all javac compile lines. Suggestion from tools folks. >> 5: Added a new shell env template. Phase 2 of hotspot test cleanup will utilize this file >> NOTE: This test_env.sh file will allow engineers to remove allot of the copy/paste of test setup from each shell testcase. >> 6: Fixed a gc testcase that was timing out on a 24 core box.. Simple fix , add a timeout. >> 7: I filed many bugs around native case issues. This changeset it not to address broken tests. Only to conform them in >> a unified way of running. >> 8: Fixing tests as defined above allows us to run the tests from a JRE. embedded use cases this is a stop gap. >> 9: In order to run jtreg with a JRE you need to define TESTJAVA (JRE - jdk/testjdk) & COMPILEJAVA (JDK - compilejdk) >> If TESTJAVA is a JDK no need to set COMPILEJAVA. >> NOTE: Most shell scripts from the command line may fail with the following issues: >> TESTSRC not defined, TESTCLASSES not defined, COMPILEJAVA path not found because we don't >> check for them at runtime. #5 above will fix this in the next phase of improving these tests to be more >> robust. >> >> Fully tested on linux-i586 builds with server/client jvm. >> >> Webrev: >> http://cr.openjdk.java.net/~collins/8009152/webrev-rev0/ >> >> Please let me know if you have any suggestions. >> Thanks >> Gary >> >> >> From Alan.Bateman at oracle.com Thu Mar 7 02:16:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 10:16:24 +0000 Subject: RFR: JDK-8009152 - A number of jtreg tests need review/improvement In-Reply-To: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> Message-ID: <513868F8.1010209@oracle.com> On 07/03/2013 00:43, Gary Collins wrote: > Request for Review > > Changes to allow better test utilization of jtreg hotspot regression tests > 1: REPLACED JAVA_HOME with TESTJAVA > 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. > NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. > NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) You are only getting this fallback when running the shell tests via jtreg. I don't know if it common for people to run the tests directly but if it is then the scripts will need to check if COMPILEJAVA is set and if not, set it to ${TESTJAVA}. I suggest this as otherwise it will be cumbersome to run the tests directly. Also the tests fail if TESTJAVA is set and they don't seem to fail if COMPILEJAVA is not set (at least for the few tests that I looked at in the webrev). -Alan. From coleen.phillimore at oracle.com Thu Mar 7 04:59:41 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Mar 2013 07:59:41 -0500 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <5137B42E.7090704@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> <5136D38C.9040100@oracle.com> <5137B42E.7090704@oracle.com> Message-ID: <51388F3D.9090302@oracle.com> I need another reviewer for this (and two for the other change). This one is really easy. You don't need to be a Reviewer. Coleen On 3/6/2013 4:25 PM, Coleen Phillimore wrote: > > Jon, > Thank you for reviewing this change. > > On 03/06/2013 12:26 AM, Jon Masamitsu wrote: >> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html >> >> >> *- ConstantPoolCache* ConstantPoolCache::allocate(ClassLoaderData* >> loader_data, int length, TRAPS) {* >> *+ int length,* >> *+ const intStack& index_map,* >> *+ const intStack& >> invokedynamic_map, TRAPS) { >> * >> >> Why did you not move the TRAP parameter to a new line? >> > > I think TRAPS aren't interesting enough and short enough not to merit > their own line. > >> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html >> >> >> Did you remove the TieredCompilation test >> >> *if (TieredCompilation) { >> * >> >> for consistency of initialization? > > Yes, I did. I don't know if people will object but I think it's more > sanitary to have these zero initialized even if they are not used in > !TieredCompilation. And I had a consistency check that I took out > that flagged these. > >> >> >> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html >> >> >> * #ifndef PRODUCT* >> * int _verify_count; // to avoid redundant verifies* >> * #endif* >> >> Not concerned about redundant verifies anymore? >> > > I moved it from Klass* to InstanceKlass* where it's used. It still > protects us from redundant verifies. > >> Rest looks good. >> > > Thanks! > Coleen > >> Jon >> >> >> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>> >>> Adding hotspot-dev to get some more potential reviewers from maybe >>> the GC team, hint... >>> >>> Coleen >>> >>> On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >>>> Summary: Zero metadata in constructors, not in allocation (and some >>>> in constructors) >>>> >>>> This seems like a good first step in passing initial values into >>>> constructors and no initializing metadata types by the callers >>>> (although a lot more parameters will have to be passed for some). >>>> >>>> Tested with runThese jck, NSK vm.quick.testlist, lang and vm jck8, >>>> java/lang/annotation jtreg tests and java/lang/invoke jtreg tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From staffan.larsen at oracle.com Thu Mar 7 08:00:35 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 07 Mar 2013 16:00:35 +0000 Subject: hg: hsx/hsx24/hotspot: 8005572: fatal error: acquiring lock JfrBuffer_lock/19 out of order with lock MethodData_lock/19 -- possible deadlock Message-ID: <20130307160045.6E0BE47DFA@hg.openjdk.java.net> Changeset: 331dc65d57d7 Author: sla Date: 2013-02-08 14:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/331dc65d57d7 8005572: fatal error: acquiring lock JfrBuffer_lock/19 out of order with lock MethodData_lock/19 -- possible deadlock Reviewed-by: mgronlun, dholmes ! src/share/vm/runtime/mutexLocker.cpp From bill.pittore at oracle.com Thu Mar 7 08:36:59 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 11:36:59 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <513748D4.3080803@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> Message-ID: <5138C22B.5070803@oracle.com> I updated the code based on the feedback. To fix the windows symbol name issue that Dean brought up I added a platform specific function, buildJniFunctionName. In windows it will properly convert _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad symbol name. Fixed copyright headers as well. Tested on linux and windows Webrevs are here: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ bill On 3/6/2013 8:47 AM, Alan Bateman wrote: > On 05/03/2013 23:05, bill.pittore at oracle.com wrote: >> This request is tied to bugid 8005716 that deals with adding support >> for statically linked JNI libraries. >> >> The JEP is here: http://openjdk.java.net/jeps/178 >> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> The main piece of functionality is to check for the presence of >> JNI_OnLoad_libname to determine if the library specified by 'libname' >> has been statically linked into the VM. If the symbol is found, it is >> assumed that the library is linked in and will not be dynamically >> loaded. > Overall I think this is quite good and follows the proposal in the > JEP. I don't see anything obvious wrong with the logic and everything > should just work for shared libraries as it does today. I assume > you'll run all the appropriate tests. > > I see Dean's suggestion to add a JVM function to allow for a lookup > table when the symbol information is available, If you do that then > you'll need to get the hotspot changes in first. Alternatively, change > what you have later once the hotspot changes are in.Just on the > > As findBuiltJniFunction can locate a built-in or a JNI_OnLoad/OnUnload > in a library then the function name is probably not quite right > (shouldn't have "Builtin" in the name). > > A minor nit in _findBuiltinLib is that if the OOME path should call > JNU_ReleaseStringPlatformChars before returning. > > There are a few commented out statements in jni_util_md.c that I > assume will be removed. Also you might want to check the indentation > in both getProcessHandle implementations as they look like 2-spaces > whereas the libs uses 4 (although this may be mute if you use a JVM > function). > > Otherwise I think this is good and I can sponsor the jdk part to this > and help get it into jdk8/tl. > > -Alan > From GARY.COLLINS at oracle.com Thu Mar 7 10:14:00 2013 From: GARY.COLLINS at oracle.com (Gary Collins) Date: Thu, 7 Mar 2013 10:14:00 -0800 Subject: RFR: JDK-8009152 - A number of jtreg tests need review/improvement In-Reply-To: <513868F8.1010209@oracle.com> References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> <513868F8.1010209@oracle.com> Message-ID: <7486BED1-9A35-4C69-88CC-0489085C2B02@oracle.com> Hi Alan, Thanks for your feedback. I agree with you. Phase 2 of cleanup will address exactly what you mention below. Compiler group is going to fix their scripts and tests to be more generic in nature where possible. Gary On Mar 7, 2013, at 2:16 AM, Alan Bateman wrote: > On 07/03/2013 00:43, Gary Collins wrote: >> Request for Review >> >> Changes to allow better test utilization of jtreg hotspot regression tests >> 1: REPLACED JAVA_HOME with TESTJAVA >> 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. >> NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. >> NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) > You are only getting this fallback when running the shell tests via jtreg. I don't know if it common for people to run the tests directly but if it is then the scripts will need to check if COMPILEJAVA is set and if not, set it to ${TESTJAVA}. I suggest this as otherwise it will be cumbersome to run the tests directly. Also the tests fail if TESTJAVA is set and they don't seem to fail if COMPILEJAVA is not set (at least for the few tests that I looked at in the webrev). > > -Alan. > From stefan.karlsson at oracle.com Thu Mar 7 10:34:16 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Thu, 07 Mar 2013 18:34:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130307183430.8FE5447E0C@hg.openjdk.java.net> Changeset: a252e688abcf Author: jmasa Date: 2013-02-01 17:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a252e688abcf 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Reviewed-by: jmasa, johnc, ysr Contributed-by: michal at frajt.eu ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: 0624b9d81255 Author: ehelin Date: 2013-03-04 13:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0624b9d81255 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp Changeset: 27714220e50e Author: johnc Date: 2013-03-04 12:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/27714220e50e 8007036: G1: Too many old regions added to last mixed GC Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: d778bb46a9a5 Author: erikj Date: 2013-03-04 22:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d778bb46a9a5 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: jcoomes, ohair ! make/bsd/makefiles/gcc.make Changeset: c71e15057f1d Author: stefank Date: 2013-03-07 14:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c71e15057f1d Merge From bill.pittore at oracle.com Thu Mar 7 10:45:02 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 13:45:02 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <5138E02E.7040804@oracle.com> On 3/7/2013 1:18 PM, Jeremy Manson wrote: > Hi guys, > > I'm really glad to see you are doing this. We've done something > similar to good effect within Google (and we'll probably drop our > similar, internal patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a > main executable that *doesn't* have a postfixed _lib? Our > Google-internal patch treats the main executable as a regular JNI > library if you execute a special System.loadFromLauncher() function. > We also do the same thing with JVMTI. > > Nit: The comments that read like this: > * for example, L, and a native library called L is statically linked > * with the VM, then the JNI_OnLoad_L function exported by the library Hows this sound. * If the filename argument, when stripped of any platform-specific library * prefix, path, and file extension, indicates a library whose name is, * for example, L, and a native library called L is statically linked * with the native application or the VM (which itself may be statically * linked into the native application), then the JNI_OnLoad_L * function exported by the library is invoked rather than attempting * to load a dynamic library. bill > Should these read "linked with the VM", or "linked with the native > application loading the VM"? > > Jeremy > > > On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette > wrote: > > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime > symbol information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of > getProcessHandle. Although your > approach is cleaner, I'm concerned about creating a VM version > dependency. For a traditional > JRE that doesn't even require static library support, we'd have to > make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their > own copy of jni.h. If they didn't > do that, we would have already gone down that path. The jdk > sources already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't > see a need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com > wrote: > >> This request is tied to bugid 8005716 that deals with adding > support for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by > 'libname' has been statically linked into the VM. If the symbol is > found, it is assumed that the library is linked in and will not be > dynamically loaded. > >> > >> thanks, > >> bill > > > > From calvin.cheung at oracle.com Thu Mar 7 10:58:39 2013 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 07 Mar 2013 10:58:39 -0800 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option In-Reply-To: <51351431.7050301@oracle.com> References: <512F7BB1.8080105@oracle.com> <5134E2CD.6070703@oracle.com> <51351431.7050301@oracle.com> Message-ID: <5138E35F.3050201@oracle.com> Looks good to me. Calvin On 3/4/2013 1:37 PM, Zhengyu Gu wrote: > Updated according to Coleen's comment. > > Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.01/ > > Thanks, > > -Zhengyu > > > On 3/4/2013 1:07 PM, Coleen Phillimore wrote: >> >> Hi Zhengyu, >> >> This looks good except one suggestion. In the lines where CALLER_PC >> appears twice, it should be called once, assigned to a variable and >> passed to both of the MemTracker functions, since CALLER_PC will walk >> the stack and it's not necessary to do it twice in a row. >> >> Otherwise, looks good. >> Coleen >> >> On 02/28/2013 10:45 AM, Zhengyu Gu wrote: >>> NMT did not probably record memory allocations from >>> os::reserve_memory_special() path, which is usually related to >>> UseLargePages VM option. >>> >>> The symptom of this bug is assertion failure in debug/fastdebug >>> build or missing Java Heap in NMT output in production build. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 >>> Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ >>> >>> To trigger the failures: >>> >>> 1. On Windows, run with -XX:+UseLargePages (with/without >>> -XX:+UseLargePagesIndividualAllocation) >>> >>> 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM >>> >>> 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM >>> >>> 4. On MacOSX, UseLargePages is disabled. >>> >>> Beware that fail to allocate large pages, does not cause JVM to >>> fail. Instead, JVM will fallback to use regular pages. >>> >>> Tests: >>> Many thanks to Christian T?rnqvist to find capable hardware and >>> figure out how to get large pages to work. We were able to test the >>> fix on Solaris sparcv9, Linux x64 and Windows x64. >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >> > From serguei.spitsyn at oracle.com Thu Mar 7 11:18:24 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 07 Mar 2013 11:18:24 -0800 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <51388F3D.9090302@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> <5136D38C.9040100@oracle.com> <5137B42E.7090704@oracle.com> <51388F3D.9090302@oracle.com> Message-ID: <5138E800.4040304@oracle.com> Coleen, It is good, but a couple of questions below. Q1: The field " _verify_count" is moved from the Klass to the InstanceKlass. But it is removed from the vmStructs.cpp. Is it because the field is NOT_PRODUCT or it is just useless for the SA? Q2: The following initializations are removed from the method.cpp:Method::Method() : 86 set_name_index(0); 87 set_signature_index(0); . . . 91 set_constants(NULL); 92 set_max_stack(0); 93 set_max_locals(0); It looks like a move in reverse direction. Are those dups? Thanks, Serguei On 3/7/13 4:59 AM, Coleen Phillimore wrote: > > I need another reviewer for this (and two for the other change). This > one is really easy. You don't need to be a Reviewer. > Coleen > > On 3/6/2013 4:25 PM, Coleen Phillimore wrote: >> >> Jon, >> Thank you for reviewing this change. >> >> On 03/06/2013 12:26 AM, Jon Masamitsu wrote: >>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html >>> >>> >>> *- ConstantPoolCache* ConstantPoolCache::allocate(ClassLoaderData* >>> loader_data, int length, TRAPS) {* >>> *+ int length,* >>> *+ const intStack& index_map,* >>> *+ const intStack& >>> invokedynamic_map, TRAPS) { >>> * >>> >>> Why did you not move the TRAP parameter to a new line? >>> >> >> I think TRAPS aren't interesting enough and short enough not to merit >> their own line. >> >>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html >>> >>> >>> Did you remove the TieredCompilation test >>> >>> *if (TieredCompilation) { >>> * >>> >>> for consistency of initialization? >> >> Yes, I did. I don't know if people will object but I think it's more >> sanitary to have these zero initialized even if they are not used in >> !TieredCompilation. And I had a consistency check that I took out >> that flagged these. >> >>> >>> >>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html >>> >>> >>> * #ifndef PRODUCT* >>> * int _verify_count; // to avoid redundant verifies* >>> * #endif* >>> >>> Not concerned about redundant verifies anymore? >>> >> >> I moved it from Klass* to InstanceKlass* where it's used. It still >> protects us from redundant verifies. >> >>> Rest looks good. >>> >> >> Thanks! >> Coleen >> >>> Jon >>> >>> >>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>> >>>> Adding hotspot-dev to get some more potential reviewers from maybe >>>> the GC team, hint... >>>> >>>> Coleen >>>> >>>> On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >>>>> Summary: Zero metadata in constructors, not in allocation (and >>>>> some in constructors) >>>>> >>>>> This seems like a good first step in passing initial values into >>>>> constructors and no initializing metadata types by the callers >>>>> (although a lot more parameters will have to be passed for some). >>>>> >>>>> Tested with runThese jck, NSK vm.quick.testlist, lang and vm jck8, >>>>> java/lang/annotation jtreg tests and java/lang/invoke jtreg tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Mar 7 11:34:57 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Mar 2013 14:34:57 -0500 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <5138E800.4040304@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> <5136D38C.9040100@oracle.com> <5137B42E.7090704@oracle.com> <51388F3D.9090302@oracle.com> <5138E800.4040304@oracle.com> Message-ID: <5138EBE1.2030905@oracle.com> Thank you for reviewing the code, Serguei. On 3/7/2013 2:18 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > It is good, but a couple of questions below. > > Q1: The field " _verify_count" is moved from the Klass to the > InstanceKlass. > But it is removed from the vmStructs.cpp. > Is it because the field is NOT_PRODUCT or it is just useless > for the SA? It was never used by the SA and doesn't really have a use in an error condition. It's used to control redundant verifies. > > Q2: The following initializations are removed from the > method.cpp:Method::Method() : > 86 set_name_index(0); > 87 set_signature_index(0); > . . . > 91 set_constants(NULL); > 92 set_max_stack(0); > 93 set_max_locals(0); > > It looks like a move in reverse direction. > Are those dups? These fields were moved to ConstMethod so are initialized in it's constructor. Thanks! Coleen > > Thanks, > Serguei > > > On 3/7/13 4:59 AM, Coleen Phillimore wrote: >> >> I need another reviewer for this (and two for the other change). This >> one is really easy. You don't need to be a Reviewer. >> Coleen >> >> On 3/6/2013 4:25 PM, Coleen Phillimore wrote: >>> >>> Jon, >>> Thank you for reviewing this change. >>> >>> On 03/06/2013 12:26 AM, Jon Masamitsu wrote: >>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html >>>> >>>> >>>> *- ConstantPoolCache* ConstantPoolCache::allocate(ClassLoaderData* >>>> loader_data, int length, TRAPS) {* >>>> *+ int length,* >>>> *+ const intStack& index_map,* >>>> *+ const intStack& >>>> invokedynamic_map, TRAPS) { >>>> * >>>> >>>> Why did you not move the TRAP parameter to a new line? >>>> >>> >>> I think TRAPS aren't interesting enough and short enough not to >>> merit their own line. >>> >>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html >>>> >>>> >>>> Did you remove the TieredCompilation test >>>> >>>> *if (TieredCompilation) { >>>> * >>>> >>>> for consistency of initialization? >>> >>> Yes, I did. I don't know if people will object but I think it's >>> more sanitary to have these zero initialized even if they are not >>> used in !TieredCompilation. And I had a consistency check that I >>> took out that flagged these. >>> >>>> >>>> >>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html >>>> >>>> >>>> * #ifndef PRODUCT* >>>> * int _verify_count; // to avoid redundant verifies* >>>> * #endif* >>>> >>>> Not concerned about redundant verifies anymore? >>>> >>> >>> I moved it from Klass* to InstanceKlass* where it's used. It still >>> protects us from redundant verifies. >>> >>>> Rest looks good. >>>> >>> >>> Thanks! >>> Coleen >>> >>>> Jon >>>> >>>> >>>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>>> >>>>> Adding hotspot-dev to get some more potential reviewers from maybe >>>>> the GC team, hint... >>>>> >>>>> Coleen >>>>> >>>>> On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >>>>>> Summary: Zero metadata in constructors, not in allocation (and >>>>>> some in constructors) >>>>>> >>>>>> This seems like a good first step in passing initial values into >>>>>> constructors and no initializing metadata types by the callers >>>>>> (although a lot more parameters will have to be passed for some). >>>>>> >>>>>> Tested with runThese jck, NSK vm.quick.testlist, lang and vm >>>>>> jck8, java/lang/annotation jtreg tests and java/lang/invoke jtreg >>>>>> tests. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Mar 7 11:48:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 07 Mar 2013 11:48:36 -0800 Subject: Review request (S) 8003553: NPG: metaspace objects should be zeroed in constructors In-Reply-To: <5138EBE1.2030905@oracle.com> References: <5134FDEF.4030007@oracle.com> <513647BE.20504@oracle.com> <5136D38C.9040100@oracle.com> <5137B42E.7090704@oracle.com> <51388F3D.9090302@oracle.com> <5138E800.4040304@oracle.com> <5138EBE1.2030905@oracle.com> Message-ID: <5138EF14.8070409@oracle.com> Ok, thanks! Serguei On 3/7/13 11:34 AM, Coleen Phillimore wrote: > > Thank you for reviewing the code, Serguei. > > On 3/7/2013 2:18 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> It is good, but a couple of questions below. >> >> Q1: The field " _verify_count" is moved from the Klass to the >> InstanceKlass. >> But it is removed from the vmStructs.cpp. >> Is it because the field is NOT_PRODUCT or it is just useless >> for the SA? > > It was never used by the SA and doesn't really have a use in an error > condition. It's used to control redundant verifies. >> >> Q2: The following initializations are removed from the >> method.cpp:Method::Method() : >> 86 set_name_index(0); >> 87 set_signature_index(0); >> . . . >> 91 set_constants(NULL); >> 92 set_max_stack(0); >> 93 set_max_locals(0); >> >> It looks like a move in reverse direction. >> Are those dups? > > These fields were moved to ConstMethod so are initialized in it's > constructor. > > Thanks! > Coleen >> >> Thanks, >> Serguei >> >> >> On 3/7/13 4:59 AM, Coleen Phillimore wrote: >>> >>> I need another reviewer for this (and two for the other change). >>> This one is really easy. You don't need to be a Reviewer. >>> Coleen >>> >>> On 3/6/2013 4:25 PM, Coleen Phillimore wrote: >>>> >>>> Jon, >>>> Thank you for reviewing this change. >>>> >>>> On 03/06/2013 12:26 AM, Jon Masamitsu wrote: >>>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/cpCache.cpp.udiff.html >>>>> >>>>> >>>>> *- ConstantPoolCache* >>>>> ConstantPoolCache::allocate(ClassLoaderData* loader_data, int >>>>> length, TRAPS) {* >>>>> *+ int length,* >>>>> *+ const intStack& index_map,* >>>>> *+ const intStack& >>>>> invokedynamic_map, TRAPS) { >>>>> * >>>>> >>>>> Why did you not move the TRAP parameter to a new line? >>>>> >>>> >>>> I think TRAPS aren't interesting enough and short enough not to >>>> merit their own line. >>>> >>>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/methodData.cpp.udiff.html >>>>> >>>>> >>>>> Did you remove the TieredCompilation test >>>>> >>>>> *if (TieredCompilation) { >>>>> * >>>>> >>>>> for consistency of initialization? >>>> >>>> Yes, I did. I don't know if people will object but I think it's >>>> more sanitary to have these zero initialized even if they are not >>>> used in !TieredCompilation. And I had a consistency check that I >>>> took out that flagged these. >>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8003553/src/share/vm/oops/klass.hpp.udiff.html >>>>> >>>>> >>>>> * #ifndef PRODUCT* >>>>> * int _verify_count; // to avoid redundant verifies* >>>>> * #endif* >>>>> >>>>> Not concerned about redundant verifies anymore? >>>>> >>>> >>>> I moved it from Klass* to InstanceKlass* where it's used. It still >>>> protects us from redundant verifies. >>>> >>>>> Rest looks good. >>>>> >>>> >>>> Thanks! >>>> Coleen >>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Adding hotspot-dev to get some more potential reviewers from >>>>>> maybe the GC team, hint... >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 03/04/2013 03:02 PM, Coleen Phillimore wrote: >>>>>>> Summary: Zero metadata in constructors, not in allocation (and >>>>>>> some in constructors) >>>>>>> >>>>>>> This seems like a good first step in passing initial values into >>>>>>> constructors and no initializing metadata types by the callers >>>>>>> (although a lot more parameters will have to be passed for some). >>>>>>> >>>>>>> Tested with runThese jck, NSK vm.quick.testlist, lang and vm >>>>>>> jck8, java/lang/annotation jtreg tests and java/lang/invoke >>>>>>> jtreg tests. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003553/ >>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003553 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Thu Mar 7 12:50:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Mar 2013 20:50:47 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <5138C22B.5070803@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> Message-ID: <5138FDA7.6040108@oracle.com> On 07/03/2013 16:36, BILL PITTORE wrote: > I updated the code based on the feedback. To fix the windows symbol > name issue that Dean brought up I added a platform specific function, > buildJniFunctionName. In windows it will properly convert > _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad > symbol name. > > Fixed copyright headers as well. > > Tested on linux and windows > > Webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > bill Thanks for sorting out the decorator issue. One comment on that part of the implementation is that findJniFunction is sizing the buffer and buildJniFunctionName is using strcpy in the components. I wonder if this could be changed so that buildJniFunctionName sizes the buffer and uses strncpy. That way it will be obviously safe when just looking at one function. It makes it easier for static analysis tools to check too. -Alan From karen.kinnear at oracle.com Thu Mar 7 12:57:32 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 7 Mar 2013 15:57:32 -0500 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513647E6.3080908@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> Message-ID: Coleen, Thank you so much for doing this and for the refactoring! A couple of minor questions/comments: 1. Did you remove set_initial_method_idnum(0) in the constructor on purpose? I had a memory that there was check for this being 0 somewhere, but maybe that is handled when you set it to methods->length() if the length is 0. 2. copy_method_ordering loops on i < methods->length() and deallocate_methods loops on <= methods->length() - 1 Any chance you could simplify to have them both loop on < methods_length() 3. In deallocate_methods If the method is NULL, did you want break or continue? I was concerned if we had a method that was NULL (due to an error) but others were not null, that they would not get freed, but we would free the array so we would lose track of them. 4. in deallocate_contents, can you add one more change that I ended up needing please? Please add an if (constants() != NULL) before the assert "shouldn't be called if anything ..." I'll do this if you don't, so no need to slow you down. 5. You don't feel like improvements to instanceKlass::print_on do you? i.e. some more if (xxx != 0) lines? If not - no worries, I'll add some when my changes go in 6. I like your valid_symbol_at and valid_klass_reference_at 7. In sort_methods, does new intArray throw on exception? 8. classFileParser.cpp line 4476 "and" -> "an" thanks, Karen On Mar 5, 2013, at 2:30 PM, Coleen Phillimore wrote: > > Resend to hotspot-dev. I don't think anyone reads hotspot-runtime-dev anymore. > Please review!! > Thanks, > Coleen > > On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >> Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. >> >> Note: I moved out code that lays out the java object into it's own function, but the diffs made it look like I made more than minor changes. The changes I made was changing class_name to _class_name and cp to _cp, and not more than that. To see these changes, you'll have to look at before/after code and not the diffs. I also tried moving this layout_fields() function around to it wouldn't false match but I wanted to keep it next to parseClassFile() and not move it too far away. >> >> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >> >> Thanks, >> Coleen >> > From bill.pittore at oracle.com Thu Mar 7 13:10:25 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 16:10:25 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5138FDA7.6040108@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> Message-ID: <51390241.6060309@oracle.com> On 3/7/2013 3:50 PM, Alan Bateman wrote: > On 07/03/2013 16:36, BILL PITTORE wrote: >> I updated the code based on the feedback. To fix the windows symbol >> name issue that Dean brought up I added a platform specific function, >> buildJniFunctionName. In windows it will properly convert >> _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad >> symbol name. >> >> Fixed copyright headers as well. >> >> Tested on linux and windows >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> bill > Thanks for sorting out the decorator issue. One comment on that part > of the implementation is that findJniFunction is sizing the buffer and > buildJniFunctionName is using strcpy in the components. I wonder if > this could be changed so that buildJniFunctionName sizes the buffer > and uses strncpy. That way it will be obviously safe when just looking > at one function. It makes it easier for static analysis tools to check > too. > I actually was passing in 'len' at one point and checking but it seemed redundant. The comment about static analysis tools having a fit makes sense. I'll tweak it as you suggest. bill > -Alan From coleen.phillimore at oracle.com Thu Mar 7 13:37:16 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Mar 2013 16:37:16 -0500 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> Message-ID: <5139088C.5040007@oracle.com> Karen, Thank you for reviewing this code. On 3/7/2013 3:57 PM, Karen Kinnear wrote: > Coleen, > > Thank you so much for doing this and for the refactoring! > > A couple of minor questions/comments: > > 1. Did you remove set_initial_method_idnum(0) in the constructor on purpose? > I had a memory that there was check for this being 0 somewhere, but maybe > that is handled when you set it to methods->length() if the length is 0. That was a mistake separating the initializations to the other changeset. I reverted it. > > 2. copy_method_ordering loops on i < methods->length() and > deallocate_methods loops on <= methods->length() - 1 > Any chance you could simplify to have them both loop on < methods_length() Yes, done. > 3. In deallocate_methods > If the method is NULL, did you want break or continue? > I was concerned if we had a method that was NULL (due to an error) but others were > not null, that they would not get freed, but we would free the array so we would lose track of them. The last element would be the one that got the error so the others will be null, but for sanity sake, I changed it to continue. > 4. in deallocate_contents, can you add one more change that I ended up needing please? > Please add an if (constants() != NULL) before the assert "shouldn't be called if anything ..." > I'll do this if you don't, so no need to slow you down. Yes added that. > 5. You don't feel like improvements to instanceKlass::print_on do you? > i.e. some more if (xxx != 0) lines? > If not - no worries, I'll add some when my changes go in Someone added print_value_on_maybe_null() which is odd. The oop versions of print_value_on() check if this == NULL which the metadata versions should also do. I didn't want to make this change now because it's in a different file. > 6. I like your valid_symbol_at and valid_klass_reference_at Two less references to _cp for each. > > 7. In sort_methods, does new intArray throw on exception? No, it's resource allocated. Eventually it might throw OOM or do something else if we can't get another thread local Arena. > 8. classFileParser.cpp line 4476 "and" -> "an" Got it. Thanks for doing the code review! Coleen > thanks, > Karen > > > On Mar 5, 2013, at 2:30 PM, Coleen Phillimore wrote: > >> Resend to hotspot-dev. I don't think anyone reads hotspot-runtime-dev anymore. >> Please review!! >> Thanks, >> Coleen >> >> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>> Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. >>> >>> Note: I moved out code that lays out the java object into it's own function, but the diffs made it look like I made more than minor changes. The changes I made was changing class_name to _class_name and cp to _cp, and not more than that. To see these changes, you'll have to look at before/after code and not the diffs. I also tried moving this layout_fields() function around to it wouldn't false match but I wanted to keep it next to parseClassFile() and not move it too far away. >>> >>> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>> >>> Thanks, >>> Coleen >>> From dean.long at oracle.com Thu Mar 7 15:26:13 2013 From: dean.long at oracle.com (Dean Long) Date: Thu, 07 Mar 2013 15:26:13 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <51392215.8020905@oracle.com> On 3/7/2013 10:18 AM, Jeremy Manson wrote: > Hi guys, > > I'm really glad to see you are doing this. We've done something > similar to good effect within Google (and we'll probably drop our > similar, internal patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a > main executable that *doesn't* have a postfixed _lib? Our > Google-internal patch treats the main executable as a regular JNI > library if you execute a special System.loadFromLauncher() function. > We also do the same thing with JVMTI. > Would that require additional changes to the JNI spec? Is there an advantage to treating it as an unnamed library rather than a named library (i.e. JNI_OnLoad_main)? dl > Nit: The comments that read like this: > * for example, L, and a native library called L is statically linked > * with the VM, then the JNI_OnLoad_L function exported by the library > Should these read "linked with the VM", or "linked with the native > application loading the VM"? > > Jeremy > > > On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette > wrote: > > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime > symbol information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of > getProcessHandle. Although your > approach is cleaner, I'm concerned about creating a VM version > dependency. For a traditional > JRE that doesn't even require static library support, we'd have to > make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their > own copy of jni.h. If they didn't > do that, we would have already gone down that path. The jdk > sources already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't > see a need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com > wrote: > >> This request is tied to bugid 8005716 that deals with adding > support for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by > 'libname' has been statically linked into the VM. If the symbol is > found, it is assumed that the library is linked in and will not be > dynamically loaded. > >> > >> thanks, > >> bill > > > > From alejandro.murillo at oracle.com Thu Mar 7 16:15:40 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Mar 2013 00:15:40 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130308001551.77B1E47E64@hg.openjdk.java.net> Changeset: 018c2639921d Author: katleman Date: 2013-03-07 11:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/018c2639921d Added tag jdk7u14-b15 for changeset 12619005c5e2 ! .hgtags Changeset: be21f8a4d42c Author: amurillo Date: 2013-03-07 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be21f8a4d42c Merge Changeset: 53152f5f34c4 Author: amurillo Date: 2013-03-07 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/53152f5f34c4 Added tag hs24-b35 for changeset be21f8a4d42c ! .hgtags From jiangli.zhou at oracle.com Thu Mar 7 17:37:16 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Fri, 08 Mar 2013 01:37:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130308013727.1564247E6D@hg.openjdk.java.net> Changeset: 7369298bec7e Author: collins Date: 2013-02-27 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7369298bec7e 7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option Summary: Small changes to hotspot tests to remove "-server" and replace with ${TESTVMOPTS} Reviewed-by: kvn ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6946040/TestCharShortByteSwap.java ! test/compiler/7068051/Test7068051.sh ! test/compiler/8000805/Test8000805.java Changeset: 5cf033ff06c4 Author: bpittore Date: 2013-03-01 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5cf033ff06c4 Merge Changeset: af5ac43f06e9 Author: jprovino Date: 2013-03-07 10:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/af5ac43f06e9 Merge Changeset: 0b8f9c8d2617 Author: jiangli Date: 2013-03-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0b8f9c8d2617 Merge From karen.kinnear at oracle.com Thu Mar 7 17:39:57 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 7 Mar 2013 20:39:57 -0500 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_HSX_Committer=3A_Markus_Gr=F6nlu?= =?iso-8859-1?Q?nd?= In-Reply-To: <512C7ACD.8090003@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> <512C7ACD.8090003@oracle.com> Message-ID: Vote: yes yeah! Karen On Feb 26, 2013, at 4:05 AM, Vladimir Ivanov wrote: > Vote: yes > > Best regards, > Vladimir Ivanov > > On 2/26/13 12:39 PM, Staffan Larsen wrote: >> I hereby nominate Markus Gr?nlund to HSX Committer. >> >> Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. >> >> http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun >> http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund >> >> Votes are due by 2013-03-12. >> >> Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Staffan Larsen >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> From bill.pittore at oracle.com Thu Mar 7 18:22:20 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 07 Mar 2013 21:22:20 -0500 Subject: Request for review- RFE 8005716 In-Reply-To: <5138FDA7.6040108@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> Message-ID: <51394B5C.2090306@oracle.com> Moved the string allocation into buildJniFunctionName as Alan suggested. Built and tested on windows and linux. Updated the webrev: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ bill On 3/7/2013 3:50 PM, Alan Bateman wrote: > On 07/03/2013 16:36, BILL PITTORE wrote: >> I updated the code based on the feedback. To fix the windows symbol >> name issue that Dean brought up I added a platform specific function, >> buildJniFunctionName. In windows it will properly convert >> _JNI_OnLoad at 8 to _JNI_OnLoad_libname at 8 as well as handle JNI_OnLoad >> symbol name. >> >> Fixed copyright headers as well. >> >> Tested on linux and windows >> >> Webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.01/ >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ >> >> bill > Thanks for sorting out the decorator issue. One comment on that part > of the implementation is that findJniFunction is sizing the buffer and > buildJniFunctionName is using strcpy in the components. I wonder if > this could be changed so that buildJniFunctionName sizes the buffer > and uses strncpy. That way it will be obviously safe when just looking > at one function. It makes it easier for static analysis tools to check > too. > > -Alan From john.coomes at oracle.com Thu Mar 7 20:34:18 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:34:18 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b80 for changeset 4873a0499bc3 Message-ID: <20130308043424.30CE547E8C@hg.openjdk.java.net> Changeset: ef3495555a4c Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ef3495555a4c Added tag jdk8-b80 for changeset 4873a0499bc3 ! .hgtags From john.coomes at oracle.com Thu Mar 7 20:34:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:34:29 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b80 for changeset b0224010e2f0 Message-ID: <20130308043433.E5D0247E93@hg.openjdk.java.net> Changeset: c88bb21560cc Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c88bb21560cc Added tag jdk8-b80 for changeset b0224010e2f0 ! .hgtags From john.coomes at oracle.com Thu Mar 7 20:34:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:34:12 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b80 for changeset 5f3d4a6bdd02 Message-ID: <20130308043413.E70D247E89@hg.openjdk.java.net> Changeset: 2a00aeeb466b Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2a00aeeb466b Added tag jdk8-b80 for changeset 5f3d4a6bdd02 ! .hgtags From john.coomes at oracle.com Thu Mar 7 20:34:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:34:08 +0000 Subject: hg: hsx/hotspot-main: 6 new changesets Message-ID: <20130308043408.7AD5847E86@hg.openjdk.java.net> Changeset: ab82853d3365 Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ab82853d3365 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: d3e3d5b06f45 Author: ohair Date: 2013-02-23 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d3e3d5b06f45 8004712: build-infra: Move user guide from web pages to repository Summary: Just the initial work, will need more changes. Reviewed-by: tbell ! README ! README-builds.html Changeset: 2778e6576e21 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2778e6576e21 Merge Changeset: 0adf9c626bb1 Author: katleman Date: 2013-02-28 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0adf9c626bb1 Merge Changeset: 907a926d3c96 Author: erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk Changeset: cd7f2c7e2a0e Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cd7f2c7e2a0e Added tag jdk8-b80 for changeset 907a926d3c96 ! .hgtags From john.coomes at oracle.com Thu Mar 7 20:34:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:34:47 +0000 Subject: hg: hsx/hotspot-main/jdk: 8 new changesets Message-ID: <20130308043712.C6C9047E99@hg.openjdk.java.net> Changeset: 5a1ea5bbe10a Author: erikj Date: 2013-02-21 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5a1ea5bbe10a 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Reviewed-by: tbell ! makefiles/Images.gmk Changeset: a287f6a0d46d Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a287f6a0d46d 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! make/common/Defs-macosx.gmk Changeset: 5d27f8702118 Author: erikj Date: 2013-02-21 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d27f8702118 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Reviewed-by: tbell, ohair ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk Changeset: f0b5b57014b3 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0b5b57014b3 Merge Changeset: 8d3dbb724859 Author: katleman Date: 2013-02-27 13:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d3dbb724859 Merge Changeset: b760d5d4b8d3 Author: katleman Date: 2013-02-28 19:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b760d5d4b8d3 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk Changeset: dfb40f066c6c Author: katleman Date: 2013-02-28 20:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dfb40f066c6c Merge Changeset: d60a95b95f01 Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d60a95b95f01 Added tag jdk8-b80 for changeset dfb40f066c6c ! .hgtags From john.coomes at oracle.com Thu Mar 7 20:39:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 04:39:24 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b80 for changeset a8227c617684 Message-ID: <20130308043931.9007F47E9C@hg.openjdk.java.net> Changeset: ed69d087fdfd Author: katleman Date: 2013-03-07 11:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ed69d087fdfd Added tag jdk8-b80 for changeset a8227c617684 ! .hgtags From mike.duigou at oracle.com Wed Mar 6 09:50:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 09:50:16 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51367A43.1060606@oracle.com> References: <51367A43.1060606@oracle.com> Message-ID: <6B264182-3ECA-46BC-94E8-9A2A02AAA6F3@oracle.com> Hi Bill; Some notes from reviewing the JDK side changes. System.java/Runtime.java: The example which begins with the name "If the filename argument, " needs to better identify that "L" is an example. (Italics?) java/lang/ClassLoader.java: NativeLibrary::fromClass could be final. ClassLoader.c: In Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib() These two values are known at compile time. int prefixLen = (int) strlen(JNI_LIB_PREFIX); int suffixLen = (int) strlen(JNI_LIB_SUFFIX); Some of the error conditions don't throw exceptions. Such as: if (cname == NULL) { return NULL; } The prefix and suffix are stripped from cname without checking that cname actually contains the prefix or suffix. if (len > prefixLen) is invariant. src/solaris/native/common/jni_util_md.c: void* getProcessHandle() { static void* procHandle = NULL; if (procHandle == NULL) { procHandle = (void*)dlopen(NULL, RTLD_LAZY); } return procHandle; } Why is the error handling code commented out? Mike On Mar 5 2013, at 15:05 , bill.pittore at oracle.com wrote: > This request is tied to bugid 8005716 that deals with adding support for statically linked JNI libraries. > > The JEP is here: http://openjdk.java.net/jeps/178 > > The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > > The webrevs are here: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > > The main piece of functionality is to check for the presence of JNI_OnLoad_libname to determine if the library specified by 'libname' has been statically linked into the VM. If the symbol is found, it is assumed that the library is linked in and will not be dynamically loaded. > > thanks, > bill From mike.duigou at oracle.com Wed Mar 6 09:56:12 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 09:56:12 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: <024FE42F-C0CB-4C01-9D3B-052B693AF80D@oracle.com> On Mar 6 2013, at 08:21 , Bob Vandette wrote: > For a traditional > JRE that doesn't even require static library support, we'd have to make sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of jni.h. In earlier days the jni.h file was copied from hotspot into jdk during the compilation process. The current build process doesn't validate that the two files match which opens up opportunities for inconsistencies and problems. > If they didn't > do that, we would have already gone down that path. If it's possible to improve upon having two jni.h instances then we should consider doing so. Mike From jeremymanson at google.com Thu Mar 7 10:18:52 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 7 Mar 2013 10:18:52 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> Message-ID: Hi guys, I'm really glad to see you are doing this. We've done something similar to good effect within Google (and we'll probably drop our similar, internal patch and pick up this patch once it is pushed). Have you thought about support for having a JNI_OnLoad inside of a main executable that *doesn't* have a postfixed _lib? Our Google-internal patch treats the main executable as a regular JNI library if you execute a special System.loadFromLauncher() function. We also do the same thing with JVMTI. Nit: The comments that read like this: * for example, L, and a native library called L is statically linked * with the VM, then the JNI_OnLoad_L function exported by the library Should these read "linked with the VM", or "linked with the native application loading the VM"? Jeremy On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette wrote: > > On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > > > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on > Windows, you can't just > > turn that into "_JNI_OnLoad at 8_" + . I think it needs to be > > "_JNI_OnLoad_" + + "@8" > > > Good catch Dean. > > > > Looks like onLoadSymbols[] is unused in > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(). > > > > Instead of adding getProcessHandle(), why not add > JVM_FindBuiltinLibraryEntry() instead? > > This would make it easier to support table-lookup when runtime symbol > information is missing or not > > supported by the platform. > > Bill has already factored out the implementation of getProcessHandle. > Although your > approach is cleaner, I'm concerned about creating a VM version dependency. > For a traditional > JRE that doesn't even require static library support, we'd have to make > sure to run on a VM that > support JNI_VERSION_1_8. It looks like the JDK maintains their own copy > of jni.h. If they didn't > do that, we would have already gone down that path. The jdk sources > already contain several > instances of dlopen, dlysym and the Windows equivalents so I don't see a > need to add a new > VM function. > > Bob. > > > > > dl > > > > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote: > >> This request is tied to bugid 8005716 that deals with adding support > for statically linked JNI libraries. > >> > >> The JEP is here: http://openjdk.java.net/jeps/178 > >> > >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716 > >> > >> The webrevs are here: > >> > >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ > >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ > >> > >> The main piece of functionality is to check for the presence of > JNI_OnLoad_libname to determine if the library specified by 'libname' has > been statically linked into the VM. If the symbol is found, it is assumed > that the library is linked in and will not be dynamically loaded. > >> > >> thanks, > >> bill > > > > From jeremymanson at google.com Thu Mar 7 17:01:53 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 7 Mar 2013 17:01:53 -0800 Subject: Request for review- RFE 8005716 In-Reply-To: <51392215.8020905@oracle.com> References: <51367A43.1060606@oracle.com> <51368F88.8000309@oracle.com> <03D91B6F-800F-4DA0-852C-6FC2D5AF06F1@oracle.com> <51392215.8020905@oracle.com> Message-ID: On Thu, Mar 7, 2013 at 3:26 PM, Dean Long wrote: > On 3/7/2013 10:18 AM, Jeremy Manson wrote: > > Hi guys, > > I'm really glad to see you are doing this. We've done something similar > to good effect within Google (and we'll probably drop our similar, internal > patch and pick up this patch once it is pushed). > > Have you thought about support for having a JNI_OnLoad inside of a main > executable that *doesn't* have a postfixed _lib? Our Google-internal patch > treats the main executable as a regular JNI library if you execute a > special System.loadFromLauncher() function. We also do the same thing with > JVMTI. > > Would that require additional changes to the JNI spec? Is there an > advantage to treating it as an unnamed library rather than > a named library (i.e. JNI_OnLoad_main)? > > A couple of advantages, neither of which is a home run, but which are worth considering: First, it means you can write libraries that are intended to be both statically and dynamically compiled without making any code changes. Maybe all this means is that JNI_OnLoad_foo should work if you are trying to load libfoo.so (maybe it already does, and I didn't see that feature.) Second, you avoid potential name clashes with dynamic libraries named the same thing. This would be most useful in adding JNI_OnLoads to general-purpose launchers, where the author of the launcher doesn't have complete control over the code that gets loaded. The only one of these I know of in the wild is in Eclipse, so let's take that as an example. I could see Eclipse bundling all of its native code into a launcher, and making itself into a single executable. Let's say an Eclipse plugin wanted to load a native library called libfoo.so, but Eclipse itself had a JNI_OnLoad_foo in its launcher. Blech. Much better for the Eclipse launcher to have a single JNI_OnLoad that delegates to initialization code for foo. (The problem is compounded when you think about the fact that these will probably be (potentially different versions of) the same library. This implies a deep, deep need to worry about visibility / using Bdynamic when compiling your launcher and your static libraries.) Jeremy From alejandro.murillo at oracle.com Thu Mar 7 23:57:21 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Mar 2013 07:57:21 +0000 Subject: hg: hsx/hsx24/hotspot: 8009687: new hotspot build - hs24-b36 Message-ID: <20130308075726.0743E47EF0@hg.openjdk.java.net> Changeset: e532bbc127b1 Author: amurillo Date: 2013-03-07 12:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e532bbc127b1 8009687: new hotspot build - hs24-b36 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Fri Mar 8 06:04:07 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Mar 2013 14:04:07 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> Hi, we have been, and still are, doing research on this issue. We want to keep you up to date on this, and propose on the further proceeding. You asked explicit memory ordering operations and a rationale why we added them. Axel found a paper describing the task queue algorithm and the needed ordering on arm and power: Correct and Efficient Work-Stealing for Weak Memory Models; L?, Pop, Cohen, Nardelli; PPoPP'13; http://www.di.ens.fr/~zappa/readings/ppopp13.pdf According to this paper we need to add one fence and one load_acquire to your implementation of the task queue. You find this fence in this small webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ With this fence, the algorithm works on Linux for our openjdk ppc port, and also for our SAP JVM . Actually, the fence fixes a problem we discovered with the concurrency torture test suite. The problem occurs with four or more GC threads. If three threads are stealing from the queue of the fourth, two of them can pop the same element. Without a fence between the access to age and bottom in pop_global(), bottom can be older than age. Unfortunately, the OpenJDK implementation with the added fence does not work on AIX. Axel already detected one place where the xlC compiler optimization removed load instruction that is required for the correctness of the algorithm. If we use our access routines with load_acquire (see original webrev below) everything works, unclear why. Now, we think C++ might allow that this load is removed and xlC does the correct, but unexpected thing. On the other hand it might also be a compiler bug. We are currently discussing this with the IBM xlC developers. Best regards, Axel and Goetz. PS: The webrev we proposed originally: http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ From vitalyd at gmail.com Fri Mar 8 06:28:54 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 8 Mar 2013 09:28:54 -0500 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? Thanks Sent from my phone On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" wrote: > Hi, > > we have been, and still are, doing research on this issue. > We want to keep you up to date on this, and propose on the > further proceeding. > > You asked explicit memory ordering operations and a rationale > why we added them. > > Axel found a paper describing the task queue algorithm and the > needed ordering on arm and power: > Correct and Efficient Work-Stealing for Weak Memory Models; > L?, Pop, Cohen, Nardelli; PPoPP'13; > http://www.di.ens.fr/~zappa/readings/ppopp13.pdf > > According to this paper we need to add one fence and one load_acquire > to your implementation of the task queue. You find this fence in this > small > webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > With this fence, the algorithm works on Linux for our openjdk ppc > port, and also for our SAP JVM . > > Actually, the fence fixes a problem we discovered with the concurrency > torture test suite. The problem occurs with four or more GC threads. > If three threads are stealing from the queue of the fourth, two of > them can pop the same element. Without a fence between the access > to age and bottom in pop_global(), bottom can be older than age. > > > Unfortunately, the OpenJDK implementation with the added fence > does not work on AIX. Axel already detected one place where the xlC > compiler optimization removed load instruction that is required for > the correctness of the algorithm. If we use our access routines with > load_acquire > (see original webrev below) everything works, unclear why. > > Now, we think C++ might allow that this load is removed and xlC does > the correct, but unexpected thing. On the other hand it might also be > a compiler bug. > We are currently discussing this with the IBM xlC developers. > > Best regards, > Axel and Goetz. > > > PS: The webrev we proposed originally: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ > > > > > > > > > From goetz.lindenmaier at sap.com Fri Mar 8 07:03:04 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Mar 2013 15:03:04 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> Hi Vitaly, No, the problem is not reordering. The problem is that _bottom, which is read after _age, might be older than _age because another processor didn't write it back yet. The fence (sync) makes the current thread wait until it has the new _bottom. On Power, a write is not visible to all other threads simultaneously (no multipl-copy-atomicity). What you propose helps if you look at two processors, but not if four threads on four processors are involved. Best regards, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Freitag, 8. M?rz 2013 15:29 To: Lindenmaier, Goetz Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker Subject: RE: RFR(M): Memory ordering in taskqueue.hpp Hi Goetz, If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? Thanks Sent from my phone On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: Hi, we have been, and still are, doing research on this issue. We want to keep you up to date on this, and propose on the further proceeding. You asked explicit memory ordering operations and a rationale why we added them. Axel found a paper describing the task queue algorithm and the needed ordering on arm and power: Correct and Efficient Work-Stealing for Weak Memory Models; L?, Pop, Cohen, Nardelli; PPoPP'13; http://www.di.ens.fr/~zappa/readings/ppopp13.pdf According to this paper we need to add one fence and one load_acquire to your implementation of the task queue. You find this fence in this small webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ With this fence, the algorithm works on Linux for our openjdk ppc port, and also for our SAP JVM . Actually, the fence fixes a problem we discovered with the concurrency torture test suite. The problem occurs with four or more GC threads. If three threads are stealing from the queue of the fourth, two of them can pop the same element. Without a fence between the access to age and bottom in pop_global(), bottom can be older than age. Unfortunately, the OpenJDK implementation with the added fence does not work on AIX. Axel already detected one place where the xlC compiler optimization removed load instruction that is required for the correctness of the algorithm. If we use our access routines with load_acquire (see original webrev below) everything works, unclear why. Now, we think C++ might allow that this load is removed and xlC does the correct, but unexpected thing. On the other hand it might also be a compiler bug. We are currently discussing this with the IBM xlC developers. Best regards, Axel and Goetz. PS: The webrev we proposed originally: http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ From vitalyd at gmail.com Fri Mar 8 07:12:58 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 8 Mar 2013 10:12:58 -0500 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> Message-ID: Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. Thanks Sent from my phone On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" wrote: > Hi Vitaly,**** > > ** ** > > No, the problem is not reordering. The problem is that **** > > _bottom, which is read after _age, might be older than _age because**** > > another processor didn?t write it back yet. The fence (sync) makes the*** > * > > current thread wait until it has the new _bottom.**** > > On Power, a write is not visible to all other threads simultaneously**** > > (no multipl-copy-atomicity).**** > > ** ** > > What you propose helps if you look at two processors, but not if **** > > four threads on four processors are involved.**** > > ** ** > > Best regards,**** > > Goetz.**** > > ** ** > > ** ** > > *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com] > *Sent:* Freitag, 8. M?rz 2013 15:29 > *To:* Lindenmaier, Goetz > *Cc:* David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; > Simonis, Volker > *Subject:* RE: RFR(M): Memory ordering in taskqueue.hpp**** > > ** ** > > Hi Goetz,**** > > If I understand correctly the problem is that bottom is loaded before age > via compiler or arch reordering. But why is a full fence needed? Is it not > sufficient to have just a load fence to load age and relaxed load (just > compiler barrier) for bottom?**** > > Thanks**** > > Sent from my phone**** > > On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote:**** > > Hi, > > we have been, and still are, doing research on this issue. > We want to keep you up to date on this, and propose on the > further proceeding. > > You asked explicit memory ordering operations and a rationale > why we added them. > > Axel found a paper describing the task queue algorithm and the > needed ordering on arm and power: > Correct and Efficient Work-Stealing for Weak Memory Models; > L?, Pop, Cohen, Nardelli; PPoPP'13; > http://www.di.ens.fr/~zappa/readings/ppopp13.pdf > > According to this paper we need to add one fence and one load_acquire > to your implementation of the task queue. You find this fence in this > small > webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > With this fence, the algorithm works on Linux for our openjdk ppc > port, and also for our SAP JVM . > > Actually, the fence fixes a problem we discovered with the concurrency > torture test suite. The problem occurs with four or more GC threads. > If three threads are stealing from the queue of the fourth, two of > them can pop the same element. Without a fence between the access > to age and bottom in pop_global(), bottom can be older than age. > > > Unfortunately, the OpenJDK implementation with the added fence > does not work on AIX. Axel already detected one place where the xlC > compiler optimization removed load instruction that is required for > the correctness of the algorithm. If we use our access routines with > load_acquire > (see original webrev below) everything works, unclear why. > > Now, we think C++ might allow that this load is removed and xlC does > the correct, but unexpected thing. On the other hand it might also be > a compiler bug. > We are currently discussing this with the IBM xlC developers. > > Best regards, > Axel and Goetz. > > > PS: The webrev we proposed originally: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ > > > > > > > > **** > From goetz.lindenmaier at sap.com Fri Mar 8 07:31:39 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Mar 2013 15:31:39 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> Hi Vitaly, the writer has a sync after the write to bottom (see pop_local) but the store and the sync are not one atomic operation. Stuff can happen before the sync is executed. Therefore the reader must sync, too. Anyways, in pop_global it should be cheaper than in pop_local. Best regards, Geotz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Freitag, 8. M?rz 2013 16:13 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker Subject: RE: RFR(M): Memory ordering in taskqueue.hpp Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. Thanks Sent from my phone On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: Hi Vitaly, No, the problem is not reordering. The problem is that _bottom, which is read after _age, might be older than _age because another processor didn't write it back yet. The fence (sync) makes the current thread wait until it has the new _bottom. On Power, a write is not visible to all other threads simultaneously (no multipl-copy-atomicity). What you propose helps if you look at two processors, but not if four threads on four processors are involved. Best regards, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Freitag, 8. M?rz 2013 15:29 To: Lindenmaier, Goetz Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker Subject: RE: RFR(M): Memory ordering in taskqueue.hpp Hi Goetz, If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? Thanks Sent from my phone On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: Hi, we have been, and still are, doing research on this issue. We want to keep you up to date on this, and propose on the further proceeding. You asked explicit memory ordering operations and a rationale why we added them. Axel found a paper describing the task queue algorithm and the needed ordering on arm and power: Correct and Efficient Work-Stealing for Weak Memory Models; L?, Pop, Cohen, Nardelli; PPoPP'13; http://www.di.ens.fr/~zappa/readings/ppopp13.pdf According to this paper we need to add one fence and one load_acquire to your implementation of the task queue. You find this fence in this small webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ With this fence, the algorithm works on Linux for our openjdk ppc port, and also for our SAP JVM . Actually, the fence fixes a problem we discovered with the concurrency torture test suite. The problem occurs with four or more GC threads. If three threads are stealing from the queue of the fourth, two of them can pop the same element. Without a fence between the access to age and bottom in pop_global(), bottom can be older than age. Unfortunately, the OpenJDK implementation with the added fence does not work on AIX. Axel already detected one place where the xlC compiler optimization removed load instruction that is required for the correctness of the algorithm. If we use our access routines with load_acquire (see original webrev below) everything works, unclear why. Now, we think C++ might allow that this load is removed and xlC does the correct, but unexpected thing. On the other hand it might also be a compiler bug. We are currently discussing this with the IBM xlC developers. Best regards, Axel and Goetz. PS: The webrev we proposed originally: http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ From volker.simonis at gmail.com Fri Mar 8 08:08:12 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Mar 2013 17:08:12 +0100 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> Message-ID: On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz wrote: > Hi Vitaly, > > the writer has a sync after the write to bottom (see pop_local) > but the store and the sync are not one atomic operation. Stuff > can happen before the sync is executed. Therefore the reader > must sync, too. > Exactly - you have three threads. The first one executes the write to bottom but not the following sync. The second thread reads this new value (by chance) and uses it but the third thread still sees the old value because there's no multipl-copy-atomicity on PPC. So we really need the sync before the read to assure thread three is not seeing an older value than thread two. > Anyways, in pop_global it should be cheaper than in pop_local. > > Best regards, > Geotz. > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: Freitag, 8. M?rz 2013 16:13 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. > > Thanks > > Sent from my phone > On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: > Hi Vitaly, > > No, the problem is not reordering. The problem is that > _bottom, which is read after _age, might be older than _age because > another processor didn't write it back yet. The fence (sync) makes the > current thread wait until it has the new _bottom. > On Power, a write is not visible to all other threads simultaneously > (no multipl-copy-atomicity). > > What you propose helps if you look at two processors, but not if > four threads on four processors are involved. > > Best regards, > Goetz. > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: Freitag, 8. M?rz 2013 15:29 > To: Lindenmaier, Goetz > Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > Hi Goetz, > > If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? > > Thanks > > Sent from my phone > On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: > Hi, > > we have been, and still are, doing research on this issue. > We want to keep you up to date on this, and propose on the > further proceeding. > > You asked explicit memory ordering operations and a rationale > why we added them. > > Axel found a paper describing the task queue algorithm and the > needed ordering on arm and power: > Correct and Efficient Work-Stealing for Weak Memory Models; > L?, Pop, Cohen, Nardelli; PPoPP'13; > http://www.di.ens.fr/~zappa/readings/ppopp13.pdf > > According to this paper we need to add one fence and one load_acquire > to your implementation of the task queue. You find this fence in this small > webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > With this fence, the algorithm works on Linux for our openjdk ppc > port, and also for our SAP JVM . > > Actually, the fence fixes a problem we discovered with the concurrency > torture test suite. The problem occurs with four or more GC threads. > If three threads are stealing from the queue of the fourth, two of > them can pop the same element. Without a fence between the access > to age and bottom in pop_global(), bottom can be older than age. > > > Unfortunately, the OpenJDK implementation with the added fence > does not work on AIX. Axel already detected one place where the xlC > compiler optimization removed load instruction that is required for > the correctness of the algorithm. If we use our access routines with load_acquire > (see original webrev below) everything works, unclear why. > > Now, we think C++ might allow that this load is removed and xlC does > the correct, but unexpected thing. On the other hand it might also be > a compiler bug. > We are currently discussing this with the IBM xlC developers. > > Best regards, > Axel and Goetz. > > > PS: The webrev we proposed originally: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ > > > > > > From vitalyd at gmail.com Fri Mar 8 08:12:33 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 8 Mar 2013 11:12:33 -0500 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> Message-ID: I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). Sent from my phone On Mar 8, 2013 11:08 AM, "Volker Simonis" wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > wrote: > > Hi Vitaly, > > > > the writer has a sync after the write to bottom (see pop_local) > > but the store and the sync are not one atomic operation. Stuff > > can happen before the sync is executed. Therefore the reader > > must sync, too. > > > > Exactly - you have three threads. The first one executes the write > to bottom but not the following sync. The second thread reads this > new value (by chance) and uses it but the third thread still sees the > old value because there's no multipl-copy-atomicity on PPC. So we > really need the sync before the read to assure thread three is not seeing > an older value than thread two. > > > Anyways, in pop_global it should be cheaper than in pop_local. > > > > Best regards, > > Geotz. > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > > Sent: Freitag, 8. M?rz 2013 16:13 > > To: Lindenmaier, Goetz > > Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; > Simonis, Volker > > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > > > > Hmm, if load fences on the reader aren't sufficient, seems like the > problem is missing order/fence on the writer? If the write isn't visible to > all processors immediately on power, shouldn't there be a fence in the > write to ensure all CPUs see it? Putting the fence in the reader seems odd, > but maybe that's just me. > > > > Thanks > > > > Sent from my phone > > On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: > > Hi Vitaly, > > > > No, the problem is not reordering. The problem is that > > _bottom, which is read after _age, might be older than _age because > > another processor didn't write it back yet. The fence (sync) makes the > > current thread wait until it has the new _bottom. > > On Power, a write is not visible to all other threads simultaneously > > (no multipl-copy-atomicity). > > > > What you propose helps if you look at two processors, but not if > > four threads on four processors are involved. > > > > Best regards, > > Goetz. > > > > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com vitalyd at gmail.com>] > > Sent: Freitag, 8. M?rz 2013 15:29 > > To: Lindenmaier, Goetz > > Cc: David Holmes; hotspot-dev at openjdk.java.net hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker > > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > > > > Hi Goetz, > > > > If I understand correctly the problem is that bottom is loaded before > age via compiler or arch reordering. But why is a full fence needed? Is it > not sufficient to have just a load fence to load age and relaxed load (just > compiler barrier) for bottom? > > > > Thanks > > > > Sent from my phone > > On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: > > Hi, > > > > we have been, and still are, doing research on this issue. > > We want to keep you up to date on this, and propose on the > > further proceeding. > > > > You asked explicit memory ordering operations and a rationale > > why we added them. > > > > Axel found a paper describing the task queue algorithm and the > > needed ordering on arm and power: > > Correct and Efficient Work-Stealing for Weak Memory Models; > > L?, Pop, Cohen, Nardelli; PPoPP'13; > > http://www.di.ens.fr/~zappa/readings/ppopp13.pdf > > > > According to this paper we need to add one fence and one load_acquire > > to your implementation of the task queue. You find this fence in this > small > > webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > > > With this fence, the algorithm works on Linux for our openjdk ppc > > port, and also for our SAP JVM . > > > > Actually, the fence fixes a problem we discovered with the concurrency > > torture test suite. The problem occurs with four or more GC threads. > > If three threads are stealing from the queue of the fourth, two of > > them can pop the same element. Without a fence between the access > > to age and bottom in pop_global(), bottom can be older than age. > > > > > > Unfortunately, the OpenJDK implementation with the added fence > > does not work on AIX. Axel already detected one place where the xlC > > compiler optimization removed load instruction that is required for > > the correctness of the algorithm. If we use our access routines with > load_acquire > > (see original webrev below) everything works, unclear why. > > > > Now, we think C++ might allow that this load is removed and xlC does > > the correct, but unexpected thing. On the other hand it might also be > > a compiler bug. > > We are currently discussing this with the IBM xlC developers. > > > > Best regards, > > Axel and Goetz. > > > > > > PS: The webrev we proposed originally: > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ > > > > > > > > > > > > > From alejandro.murillo at oracle.com Fri Mar 8 09:19:33 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Mar 2013 17:19:33 +0000 Subject: hg: hsx/hotspot-main/jdk: 8009384: Temporarily disable jstat tests to ease complicated push Message-ID: <20130308172004.D6FD64800C@hg.openjdk.java.net> Changeset: 758db1c4c65c Author: ehelin Date: 2013-03-04 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/758db1c4c65c 8009384: Temporarily disable jstat tests to ease complicated push Reviewed-by: mchung ! test/ProblemList.txt From alejandro.murillo at oracle.com Fri Mar 8 12:12:32 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Mar 2013 20:12:32 +0000 Subject: hg: hsx/hsx25/hotspot: 35 new changesets Message-ID: <20130308201420.46EC848016@hg.openjdk.java.net> Changeset: fbda7e1dee9a Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fbda7e1dee9a Added tag jdk8-b80 for changeset 4a198b201f3c ! .hgtags Changeset: 7f482030ff64 Author: amurillo Date: 2013-03-01 04:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7f482030ff64 8009226: new hotspot build - hs25-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1f9994892f89 Author: stefank Date: 2013-02-21 17:22 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f9994892f89 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders. Reviewed-by: coleenp, acorn Contributed-by: Stefan Karlsson , Erik Helin ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3c9db54c2660 Author: mikael Date: 2013-02-26 08:54 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c9db54c2660 8008081: Print outs do not have matching arguments Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function Reviewed-by: sla, dholmes ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/memReporter.cpp ! src/share/vm/utilities/numberSeq.cpp Changeset: 05f2fc6b4ea7 Author: dholmes Date: 2013-02-27 04:58 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/05f2fc6b4ea7 Merge Changeset: 96bd4772ec62 Author: kevinw Date: 2013-02-27 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/96bd4772ec62 8008807: SA: jstack crash when target has mismatched bitness (Linux) Reviewed-by: rbackman, sla, poonam ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 698b615a1cde Author: kevinw Date: 2013-02-27 16:40 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/698b615a1cde Merge Changeset: 651919d134f7 Author: kevinw Date: 2013-02-27 22:40 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/651919d134f7 7178741: SA: jstack -m produce UnalignedAddressException in output (Linux) Reviewed-by: poonam, sla ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java Changeset: 5ee250974db9 Author: dcubed Date: 2013-02-27 15:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ee250974db9 8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock. Reviewed-by: sla, acorn ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/threadService.cpp Changeset: a140cd925462 Author: dcubed Date: 2013-02-28 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a140cd925462 Merge Changeset: 63e54c37ac64 Author: simonis Date: 2013-02-27 09:40 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/63e54c37ac64 8008959: Fix non-PCH build on Linux, Windows and MacOS X Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files. Reviewed-by: coleenp, stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: a506ac816f14 Author: coleenp Date: 2013-02-27 07:35 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a506ac816f14 Merge Changeset: 143973ced9ab Author: coleenp Date: 2013-02-28 18:37 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/143973ced9ab Merge Changeset: 3e83d69c19db Author: dcubed Date: 2013-03-01 15:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3e83d69c19db Merge Changeset: a252e688abcf Author: jmasa Date: 2013-02-01 17:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a252e688abcf 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Reviewed-by: jmasa, johnc, ysr Contributed-by: michal at frajt.eu ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: 0624b9d81255 Author: ehelin Date: 2013-03-04 13:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0624b9d81255 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp Changeset: 27714220e50e Author: johnc Date: 2013-03-04 12:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/27714220e50e 8007036: G1: Too many old regions added to last mixed GC Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: d778bb46a9a5 Author: erikj Date: 2013-03-04 22:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d778bb46a9a5 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: jcoomes, ohair ! make/bsd/makefiles/gcc.make Changeset: c71e15057f1d Author: stefank Date: 2013-03-07 14:29 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c71e15057f1d Merge Changeset: 7369298bec7e Author: collins Date: 2013-02-27 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7369298bec7e 7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option Summary: Small changes to hotspot tests to remove "-server" and replace with ${TESTVMOPTS} Reviewed-by: kvn ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6946040/TestCharShortByteSwap.java ! test/compiler/7068051/Test7068051.sh ! test/compiler/8000805/Test8000805.java Changeset: 5cf033ff06c4 Author: bpittore Date: 2013-03-01 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5cf033ff06c4 Merge Changeset: af5ac43f06e9 Author: jprovino Date: 2013-03-07 10:46 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/af5ac43f06e9 Merge Changeset: 0b8f9c8d2617 Author: jiangli Date: 2013-03-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0b8f9c8d2617 Merge Changeset: 40b7c6b800ab Author: morris Date: 2013-03-01 14:26 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/40b7c6b800ab 8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m Summary: Fix unitialized variable and return value. Reviewed-by: kvn ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: bf06968a8a00 Author: morris Date: 2013-03-04 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf06968a8a00 8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value Summary: safety checks for non-Apple thread time functions Reviewed-by: kvn ! src/os/bsd/vm/os_bsd.cpp Changeset: c40fbf634c90 Author: morris Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c40fbf634c90 8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp Summary: fix null pointer Reviewed-by: kvn ! src/share/vm/runtime/frame.cpp Changeset: 571076d3c79d Author: shade Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/571076d3c79d 8009120: Fuzz instruction scheduling in HotSpot compilers Reviewed-by: kvn, vlivanov ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 4f553e24b3b5 Author: vlivanov Date: 2013-03-05 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4f553e24b3b5 Merge Changeset: 872b3feace55 Author: morris Date: 2013-03-05 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/872b3feace55 8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp Summary: fix null pointer Reviewed-by: kvn, coleenp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 8651f608fea4 Author: roland Date: 2013-03-06 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8651f608fea4 8009460: C2compiler crash in machnode::in_regmask(unsigned int) Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: ff55877839bc Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff55877839bc 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: bdb602473679 Author: morris Date: 2013-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bdb602473679 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: b5bd25d55994 Author: morris Date: 2013-03-07 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5bd25d55994 Merge Changeset: dd6350b4abc4 Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dd6350b4abc4 Merge Changeset: 65b797426a3b Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/65b797426a3b Added tag hs25-b22 for changeset dd6350b4abc4 ! .hgtags From alejandro.murillo at oracle.com Fri Mar 8 13:53:27 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Mar 2013 21:53:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130308215339.8FAAB4801D@hg.openjdk.java.net> Changeset: fbda7e1dee9a Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fbda7e1dee9a Added tag jdk8-b80 for changeset 4a198b201f3c ! .hgtags Changeset: dd6350b4abc4 Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dd6350b4abc4 Merge Changeset: 65b797426a3b Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/65b797426a3b Added tag hs25-b22 for changeset dd6350b4abc4 ! .hgtags Changeset: 8196357e95b5 Author: amurillo Date: 2013-03-08 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8196357e95b5 8009688: new hotspot build - hs25-b23 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Fri Mar 8 15:41:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 09 Mar 2013 09:41:28 +1000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> Message-ID: <513A7728.8010303@oracle.com> On 9/03/2013 2:08 AM, Volker Simonis wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > wrote: >> Hi Vitaly, >> >> the writer has a sync after the write to bottom (see pop_local) >> but the store and the sync are not one atomic operation. Stuff >> can happen before the sync is executed. Therefore the reader >> must sync, too. >> > > Exactly - you have three threads. The first one executes the write > to bottom but not the following sync. The second thread reads this > new value (by chance) and uses it but the third thread still sees the > old value because there's no multipl-copy-atomicity on PPC. So we > really need the sync before the read to assure thread three is not seeing > an older value than thread two. That doesn't quite make sense to me in isolation because thread two could read the old value just before thread one writes the new one anyway. I would think there would have to be a reordering issue as well, and that is what the sync would fix. (I haven't read the paper.) David >> Anyways, in pop_global it should be cheaper than in pop_local. >> >> Best regards, >> Geotz. >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 16:13 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: >> Hi Vitaly, >> >> No, the problem is not reordering. The problem is that >> _bottom, which is read after _age, might be older than _age because >> another processor didn't write it back yet. The fence (sync) makes the >> current thread wait until it has the new _bottom. >> On Power, a write is not visible to all other threads simultaneously >> (no multipl-copy-atomicity). >> >> What you propose helps if you look at two processors, but not if >> four threads on four processors are involved. >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 15:29 >> To: Lindenmaier, Goetz >> Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hi Goetz, >> >> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: >> Hi, >> >> we have been, and still are, doing research on this issue. >> We want to keep you up to date on this, and propose on the >> further proceeding. >> >> You asked explicit memory ordering operations and a rationale >> why we added them. >> >> Axel found a paper describing the task queue algorithm and the >> needed ordering on arm and power: >> Correct and Efficient Work-Stealing for Weak Memory Models; >> L?, Pop, Cohen, Nardelli; PPoPP'13; >> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >> >> According to this paper we need to add one fence and one load_acquire >> to your implementation of the task queue. You find this fence in this small >> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> With this fence, the algorithm works on Linux for our openjdk ppc >> port, and also for our SAP JVM . >> >> Actually, the fence fixes a problem we discovered with the concurrency >> torture test suite. The problem occurs with four or more GC threads. >> If three threads are stealing from the queue of the fourth, two of >> them can pop the same element. Without a fence between the access >> to age and bottom in pop_global(), bottom can be older than age. >> >> >> Unfortunately, the OpenJDK implementation with the added fence >> does not work on AIX. Axel already detected one place where the xlC >> compiler optimization removed load instruction that is required for >> the correctness of the algorithm. If we use our access routines with load_acquire >> (see original webrev below) everything works, unclear why. >> >> Now, we think C++ might allow that this load is removed and xlC does >> the correct, but unexpected thing. On the other hand it might also be >> a compiler bug. >> We are currently discussing this with the IBM xlC developers. >> >> Best regards, >> Axel and Goetz. >> >> >> PS: The webrev we proposed originally: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >> >> >> >> >> >> From jon.masamitsu at oracle.com Fri Mar 8 16:19:26 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 08 Mar 2013 16:19:26 -0800 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513647E6.3080908@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> Message-ID: <513A800E.6030902@oracle.com> Coleen, http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html *+ // metadata created before the instance klass is created. Must be* *+ // deallocated if classfile parsing returns an error.* Could this also have said "Must be deallocated if not transferred to the InstanceKlass upon sucessful class loading in which case these pointers have been set to NULL." At first I didn't understand why the destructor didn't always deallocate the metadata. Can all the fields with pointers to metadata be grouped together and in the destructor iterate through the pointers to see that they are all NULL? Worth doing to catch leaks? This file just had so many changes in it I quickly bogged down. I'll try again later. So far only http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html 2991 // Assign allocations if needed allocations or annotations? Can you make this unsigned? 3288 int map_count = _super_klass->nonstatic_oop_map_count(); Jon On 3/5/2013 11:30 AM, Coleen Phillimore wrote: > > Resend to hotspot-dev. I don't think anyone reads > hotspot-runtime-dev anymore. > Please review!! > Thanks, > Coleen > > On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >> Summary: Store metadata on ClassFileParser instance to be cleaned up >> by destructor. This enabled some refactoring of the enormous >> parseClassFile function. >> >> Note: I moved out code that lays out the java object into it's own >> function, but the diffs made it look like I made more than minor >> changes. The changes I made was changing class_name to _class_name >> and cp to _cp, and not more than that. To see these changes, you'll >> have to look at before/after code and not the diffs. I also tried >> moving this layout_fields() function around to it wouldn't false >> match but I wanted to keep it next to parseClassFile() and not move >> it too far away. >> >> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, >> java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Sat Mar 9 07:01:47 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Sat, 09 Mar 2013 10:01:47 -0500 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513A800E.6030902@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> <513A800E.6030902@oracle.com> Message-ID: <513B4EDB.9060509@oracle.com> Hi Jon, Thank you for starting to look at this. The huge number of diffs in classFileParser.cpp is because I moved the code that laid out fields and diff matches oddly so it looks like I changed a lot more than I did. I should have done this in the first place, but here are the changes I made without moving layout_fields. I'll move it back (and remove the fac and parsed_allocations copying) after the review. http://cr.openjdk.java.net/~coleenp/8003419_small/ This is much easier to read! On 3/8/2013 7:19 PM, Jon Masamitsu wrote: > Coleen, > > http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html > > > *+ // metadata created before the instance klass is created. Must be* > *+ // deallocated if classfile parsing returns an error.* > > Could this also have said > > "Must be deallocated if not transferred to the InstanceKlass upon > sucessful class loading > in which case these pointers have been set to NULL." I changed the comment (adding a 'c' to it) to yours. > > At first I didn't understand why the destructor didn't always > deallocate the > metadata. > > Can all the fields with pointers to metadata be grouped together > and in the destructor iterate through the pointers to see that they are > all NULL? Worth doing to catch leaks? The deallocation uses template functions for the types of each pointer so iterating through pointers won't work. > > > This file just had so many changes in it I quickly bogged down. I'll > try again later. So far only > > http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html > > > 2991 // Assign allocations if needed > > allocations or annotations? > Annotations, fixed. > Can you make this unsigned? > > 3288 int map_count = _super_klass->nonstatic_oop_map_count(); > Yes, I changed it. The field nonstatic_oop_map_count is unsigned. Thanks! Coleen > > > Jon > > > On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >> >> Resend to hotspot-dev. I don't think anyone reads >> hotspot-runtime-dev anymore. >> Please review!! >> Thanks, >> Coleen >> >> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>> Summary: Store metadata on ClassFileParser instance to be cleaned up >>> by destructor. This enabled some refactoring of the enormous >>> parseClassFile function. >>> >>> Note: I moved out code that lays out the java object into it's own >>> function, but the diffs made it look like I made more than minor >>> changes. The changes I made was changing class_name to _class_name >>> and cp to _cp, and not more than that. To see these changes, >>> you'll have to look at before/after code and not the diffs. I also >>> tried moving this layout_fields() function around to it wouldn't >>> false match but I wanted to keep it next to parseClassFile() and not >>> move it too far away. >>> >>> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, >>> java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>> >>> Thanks, >>> Coleen >>> >> > From goetz.lindenmaier at sap.com Mon Mar 11 01:39:04 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Mar 2013 08:39:04 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <513A7728.8010303@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <513A7728.8010303@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFA9F55@DEWDFEMB12A.global.corp.sap> Hi David, It's a prerequisite that thread two reads the new value of bottom. It it doesn't, there is no problem. Thread three will read the new value of age, because that is written with cmpxchg. And if thread three sees a bottom older than thread two that is inconsistent. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Samstag, 9. M?rz 2013 00:41 To: Volker Simonis Cc: Lindenmaier, Goetz; Vitaly Davidovich; Simonis, Volker; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): Memory ordering in taskqueue.hpp On 9/03/2013 2:08 AM, Volker Simonis wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > wrote: >> Hi Vitaly, >> >> the writer has a sync after the write to bottom (see pop_local) >> but the store and the sync are not one atomic operation. Stuff >> can happen before the sync is executed. Therefore the reader >> must sync, too. >> > > Exactly - you have three threads. The first one executes the write > to bottom but not the following sync. The second thread reads this > new value (by chance) and uses it but the third thread still sees the > old value because there's no multipl-copy-atomicity on PPC. So we > really need the sync before the read to assure thread three is not seeing > an older value than thread two. That doesn't quite make sense to me in isolation because thread two could read the old value just before thread one writes the new one anyway. I would think there would have to be a reordering issue as well, and that is what the sync would fix. (I haven't read the paper.) David >> Anyways, in pop_global it should be cheaper than in pop_local. >> >> Best regards, >> Geotz. >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 16:13 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: >> Hi Vitaly, >> >> No, the problem is not reordering. The problem is that >> _bottom, which is read after _age, might be older than _age because >> another processor didn't write it back yet. The fence (sync) makes the >> current thread wait until it has the new _bottom. >> On Power, a write is not visible to all other threads simultaneously >> (no multipl-copy-atomicity). >> >> What you propose helps if you look at two processors, but not if >> four threads on four processors are involved. >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 15:29 >> To: Lindenmaier, Goetz >> Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hi Goetz, >> >> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: >> Hi, >> >> we have been, and still are, doing research on this issue. >> We want to keep you up to date on this, and propose on the >> further proceeding. >> >> You asked explicit memory ordering operations and a rationale >> why we added them. >> >> Axel found a paper describing the task queue algorithm and the >> needed ordering on arm and power: >> Correct and Efficient Work-Stealing for Weak Memory Models; >> L?, Pop, Cohen, Nardelli; PPoPP'13; >> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >> >> According to this paper we need to add one fence and one load_acquire >> to your implementation of the task queue. You find this fence in this small >> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> With this fence, the algorithm works on Linux for our openjdk ppc >> port, and also for our SAP JVM . >> >> Actually, the fence fixes a problem we discovered with the concurrency >> torture test suite. The problem occurs with four or more GC threads. >> If three threads are stealing from the queue of the fourth, two of >> them can pop the same element. Without a fence between the access >> to age and bottom in pop_global(), bottom can be older than age. >> >> >> Unfortunately, the OpenJDK implementation with the added fence >> does not work on AIX. Axel already detected one place where the xlC >> compiler optimization removed load instruction that is required for >> the correctness of the algorithm. If we use our access routines with load_acquire >> (see original webrev below) everything works, unclear why. >> >> Now, we think C++ might allow that this load is removed and xlC does >> the correct, but unexpected thing. On the other hand it might also be >> a compiler bug. >> We are currently discussing this with the IBM xlC developers. >> >> Best regards, >> Axel and Goetz. >> >> >> PS: The webrev we proposed originally: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >> >> >> >> >> >> From david.r.chase at oracle.com Mon Mar 11 05:24:18 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 11 Mar 2013 08:24:18 -0400 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFA9F55@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <513A7728.8010303@o! racle.com> <4295855A5C1DE049A61835A1887419CC0CFA9F55@DEWDFEMB12A.global.corp.sap> Message-ID: <7A12E271-0134-4373-9AFE-EF6F4A7E21A1@oracle.com> I should have been paying a little more attention to this, and will read ppopp13 carefully later this morning, but in the original Chase-Lev algorithm we did have memory barriers, but removed them because "that is not house style for SPAA" (!!!!!!!!!!!!!!!) That paper includes one more memory barrier than we had anticipated; given that they have real weak-consistency hardware to test on, and a proof to go with it, I would trust their paper (mostly -- I would not presume to use fewer barriers). Except for the growing/shrinking queue, Chase/Lev pretty carefully follows the original ABP design, so it's also likely to apply in the case of ABP-derived queues that don't grow or shrink. David On 2013-03-11, at 4:39 AM, "Lindenmaier, Goetz" wrote: > Hi David, > > It's a prerequisite that thread two reads the new value of bottom. > It it doesn't, there is no problem. > > Thread three will read the new value of age, because that is > written with cmpxchg. And if thread three sees a > bottom older than thread two that is inconsistent. > > Best regards, > Goetz. > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Samstag, 9. M?rz 2013 00:41 > To: Volker Simonis > Cc: Lindenmaier, Goetz; Vitaly Davidovich; Simonis, Volker; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > On 9/03/2013 2:08 AM, Volker Simonis wrote: >> On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz >> wrote: >>> Hi Vitaly, >>> >>> the writer has a sync after the write to bottom (see pop_local) >>> but the store and the sync are not one atomic operation. Stuff >>> can happen before the sync is executed. Therefore the reader >>> must sync, too. >>> >> >> Exactly - you have three threads. The first one executes the write >> to bottom but not the following sync. The second thread reads this >> new value (by chance) and uses it but the third thread still sees the >> old value because there's no multipl-copy-atomicity on PPC. So we >> really need the sync before the read to assure thread three is not seeing >> an older value than thread two. > > That doesn't quite make sense to me in isolation because thread two > could read the old value just before thread one writes the new one > anyway. I would think there would have to be a reordering issue as well, > and that is what the sync would fix. (I haven't read the paper.) > > David > >>> Anyways, in pop_global it should be cheaper than in pop_local. >>> >>> Best regards, >>> Geotz. >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 16:13 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" > wrote: >>> Hi Vitaly, >>> >>> No, the problem is not reordering. The problem is that >>> _bottom, which is read after _age, might be older than _age because >>> another processor didn't write it back yet. The fence (sync) makes the >>> current thread wait until it has the new _bottom. >>> On Power, a write is not visible to all other threads simultaneously >>> (no multipl-copy-atomicity). >>> >>> What you propose helps if you look at two processors, but not if >>> four threads on four processors are involved. >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 15:29 >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; hotspot-dev at openjdk.java.net; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hi Goetz, >>> >>> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" > wrote: >>> Hi, >>> >>> we have been, and still are, doing research on this issue. >>> We want to keep you up to date on this, and propose on the >>> further proceeding. >>> >>> You asked explicit memory ordering operations and a rationale >>> why we added them. >>> >>> Axel found a paper describing the task queue algorithm and the >>> needed ordering on arm and power: >>> Correct and Efficient Work-Stealing for Weak Memory Models; >>> L?, Pop, Cohen, Nardelli; PPoPP'13; >>> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >>> >>> According to this paper we need to add one fence and one load_acquire >>> to your implementation of the task queue. You find this fence in this small >>> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>> >>> With this fence, the algorithm works on Linux for our openjdk ppc >>> port, and also for our SAP JVM . >>> >>> Actually, the fence fixes a problem we discovered with the concurrency >>> torture test suite. The problem occurs with four or more GC threads. >>> If three threads are stealing from the queue of the fourth, two of >>> them can pop the same element. Without a fence between the access >>> to age and bottom in pop_global(), bottom can be older than age. >>> >>> >>> Unfortunately, the OpenJDK implementation with the added fence >>> does not work on AIX. Axel already detected one place where the xlC >>> compiler optimization removed load instruction that is required for >>> the correctness of the algorithm. If we use our access routines with load_acquire >>> (see original webrev below) everything works, unclear why. >>> >>> Now, we think C++ might allow that this load is removed and xlC does >>> the correct, but unexpected thing. On the other hand it might also be >>> a compiler bug. >>> We are currently discussing this with the IBM xlC developers. >>> >>> Best regards, >>> Axel and Goetz. >>> >>> >>> PS: The webrev we proposed originally: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>> >>> >>> >>> >>> >>> From Alan.Bateman at oracle.com Mon Mar 11 06:40:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2013 13:40:26 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <51394B5C.2090306@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> Message-ID: <513DDECA.7090003@oracle.com> On 08/03/2013 02:22, BILL PITTORE wrote: > Moved the string allocation into buildJniFunctionName as Alan > suggested. Built and tested on windows and linux. Updated the webrev: > > http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ > > > bill I see this updates the method descriptions to take on board Jeremy's comment on the possibility of the library being statically linked with the main executable with or without the VM. To be complete, I think this will require an update to the UnstatisfiedLinkError description too. Thanks for moving the sizing/allocation of the function name into buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX really the right limit to impose? A minor point, but the buffer is overrsized by 1 for the shared library case, I think it should be: len = strlen(sym) + (cname != NULL ? strlen(cname)+1 : 0) + 1 Otherwise, I think the implementation looks good to me. -Alan. From bill.pittore at oracle.com Mon Mar 11 08:37:01 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 11 Mar 2013 11:37:01 -0400 Subject: Request for review- RFE 8005716 In-Reply-To: <513DDECA.7090003@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> <513DDECA.7090003@oracle.com> Message-ID: <513DFA1D.1000902@oracle.com> On 3/11/2013 9:40 AM, Alan Bateman wrote: > On 08/03/2013 02:22, BILL PITTORE wrote: >> Moved the string allocation into buildJniFunctionName as Alan >> suggested. Built and tested on windows and linux. Updated the webrev: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ >> >> >> bill > I see this updates the method descriptions to take on board Jeremy's > comment on the possibility of the library being statically linked with > the main executable with or without the VM. To be complete, I think > this will require an update to the UnstatisfiedLinkError description too. > > Thanks for moving the sizing/allocation of the function name into > buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX > really the right limit to impose? Maybe JVM_MAXPATHLEN is the better choice. > > A minor point, but the buffer is overrsized by 1 for the shared > library case, I think it should be: > len = strlen(sym) + (cname != NULL ? strlen(cname)+1 : 0) + 1 The +2 covered both cases; but re-wrote it to be the more explicit version above. bill > > Otherwise, I think the implementation looks good to me. > > -Alan. > > > > From adomurad at redhat.com Mon Mar 11 09:16:01 2013 From: adomurad at redhat.com (Adam Domurad) Date: Mon, 11 Mar 2013 12:16:01 -0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <5130D0AB.8000001@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> <5130D0AB.8000001@oracle.com> Message-ID: <513E0341.4090400@redhat.com> On 03/01/2013 11:00 AM, Dmitry Samersoff wrote: > Adam, > > Thank you for advice! I'm looking for a possibility to remove > get_stack_bounds function entirely as Dean suggested. But it takes some > time. Hi again, not to be a bother, but do you have a rough time-frame that the fix will take? Thanks, -Adam From dmitry.samersoff at oracle.com Mon Mar 11 10:19:12 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Mar 2013 21:19:12 +0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <513780C0.9050103@redhat.com> References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> <5130D0AB.8000001@oracle.com> <513780C0.9050103@redhat.com> Message-ID: <513E1210.4030406@oracle.com> Adam, Sorry! I can't provide any estimations right now. But it's a high priority issue in my queue, and I plan to provide a fix as soon as it become possible. -Dmitry On 2013-03-06 21:45, Adam Domurad wrote: > On 03/01/2013 11:00 AM, Dmitry Samersoff wrote: >> Adam, >> >> Thank you for advice! I'm looking for a possibility to remove >> get_stack_bounds function entirely as Dean suggested. But it takes some >> time. > > Hi again, not to be a bother, but do you have a rough time-frame that > the fix will take? > > Thanks, > -Adam -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From jon.masamitsu at oracle.com Mon Mar 11 10:43:30 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 10:43:30 -0700 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513B4EDB.9060509@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> <513A800E.6030902@oracle.com> <513B4EDB.9060509@oracle.com> Message-ID: <513E17C2.3020602@oracle.com> On 03/09/13 07:01, Coleen Phillmore wrote: > > Hi Jon, > > Thank you for starting to look at this. The huge number of diffs in > classFileParser.cpp is because I moved the code that laid out fields > and diff matches oddly so it looks like I changed a lot more than I > did. I should have done this in the first place, but here are the > changes I made without moving layout_fields. I'll move it back (and > remove the fac and parsed_allocations copying) after the review. > > http://cr.openjdk.java.net/~coleenp/8003419_small/ > > This is much easier to read! Thanks. This helps. The description for apply_parsed_class_metadata() is *+ // Transfer ownership of metadata allocated to the InstanceKlass. When apply_parsed_class_metadata() all the metadata for the Klass has been allocated and is hanging off the ClassFileParser? Jon * > > On 3/8/2013 7:19 PM, Jon Masamitsu wrote: >> Coleen, >> >> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html >> >> >> *+ // metadata created before the instance klass is created. Must be* >> *+ // deallocated if classfile parsing returns an error.* >> >> Could this also have said >> >> "Must be deallocated if not transferred to the InstanceKlass upon >> sucessful class loading >> in which case these pointers have been set to NULL." > > I changed the comment (adding a 'c' to it) to yours. >> >> At first I didn't understand why the destructor didn't always >> deallocate the >> metadata. >> >> Can all the fields with pointers to metadata be grouped together >> and in the destructor iterate through the pointers to see that they are >> all NULL? Worth doing to catch leaks? > > The deallocation uses template functions for the types of each pointer > so iterating through pointers won't work. >> >> >> This file just had so many changes in it I quickly bogged down. I'll >> try again later. So far only >> >> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html >> >> >> 2991 // Assign allocations if needed >> >> allocations or annotations? >> > > Annotations, fixed. >> Can you make this unsigned? >> >> 3288 int map_count = _super_klass->nonstatic_oop_map_count(); >> > > Yes, I changed it. The field nonstatic_oop_map_count is unsigned. > > Thanks! > Coleen > >> >> >> Jon >> >> >> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>> >>> Resend to hotspot-dev. I don't think anyone reads >>> hotspot-runtime-dev anymore. >>> Please review!! >>> Thanks, >>> Coleen >>> >>> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>>> Summary: Store metadata on ClassFileParser instance to be cleaned >>>> up by destructor. This enabled some refactoring of the enormous >>>> parseClassFile function. >>>> >>>> Note: I moved out code that lays out the java object into it's own >>>> function, but the diffs made it look like I made more than minor >>>> changes. The changes I made was changing class_name to _class_name >>>> and cp to _cp, and not more than that. To see these changes, >>>> you'll have to look at before/after code and not the diffs. I also >>>> tried moving this layout_fields() function around to it wouldn't >>>> false match but I wanted to keep it next to parseClassFile() and >>>> not move it too far away. >>>> >>>> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, >>>> java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> > From coleen.phillimore at oracle.com Mon Mar 11 10:57:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Mar 2013 13:57:31 -0400 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513E17C2.3020602@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> <513A800E.6030902@oracle.com> <513B4EDB.9060509@oracle.com> <513E17C2.3020602@oracle.com> Message-ID: <513E1B0B.9070902@oracle.com> On 3/11/2013 1:43 PM, Jon Masamitsu wrote: > > > On 03/09/13 07:01, Coleen Phillmore wrote: >> >> Hi Jon, >> >> Thank you for starting to look at this. The huge number of diffs in >> classFileParser.cpp is because I moved the code that laid out fields >> and diff matches oddly so it looks like I changed a lot more than I >> did. I should have done this in the first place, but here are the >> changes I made without moving layout_fields. I'll move it back (and >> remove the fac and parsed_allocations copying) after the review. >> >> http://cr.openjdk.java.net/~coleenp/8003419_small/ >> >> This is much easier to read! > > Thanks. This helps. > > The description for apply_parsed_class_metadata() is > > *+ // Transfer ownership of metadata allocated to the InstanceKlass. > > When apply_parsed_class_metadata() all the metadata for > the Klass has been allocated and is hanging off the > ClassFileParser? Yes. Coleen > > Jon > > * > > > >> >> On 3/8/2013 7:19 PM, Jon Masamitsu wrote: >>> Coleen, >>> >>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html >>> >>> >>> *+ // metadata created before the instance klass is created. Must >>> be* >>> *+ // deallocated if classfile parsing returns an error.* >>> >>> Could this also have said >>> >>> "Must be deallocated if not transferred to the InstanceKlass upon >>> sucessful class loading >>> in which case these pointers have been set to NULL." >> >> I changed the comment (adding a 'c' to it) to yours. >>> >>> At first I didn't understand why the destructor didn't always >>> deallocate the >>> metadata. >>> >>> Can all the fields with pointers to metadata be grouped together >>> and in the destructor iterate through the pointers to see that they are >>> all NULL? Worth doing to catch leaks? >> >> The deallocation uses template functions for the types of each >> pointer so iterating through pointers won't work. >>> >>> >>> This file just had so many changes in it I quickly bogged down. I'll >>> try again later. So far only >>> >>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html >>> >>> >>> 2991 // Assign allocations if needed >>> >>> allocations or annotations? >>> >> >> Annotations, fixed. >>> Can you make this unsigned? >>> >>> 3288 int map_count = _super_klass->nonstatic_oop_map_count(); >>> >> >> Yes, I changed it. The field nonstatic_oop_map_count is unsigned. >> >> Thanks! >> Coleen >> >>> >>> >>> Jon >>> >>> >>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>> >>>> Resend to hotspot-dev. I don't think anyone reads >>>> hotspot-runtime-dev anymore. >>>> Please review!! >>>> Thanks, >>>> Coleen >>>> >>>> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>>>> Summary: Store metadata on ClassFileParser instance to be cleaned >>>>> up by destructor. This enabled some refactoring of the enormous >>>>> parseClassFile function. >>>>> >>>>> Note: I moved out code that lays out the java object into it's own >>>>> function, but the diffs made it look like I made more than minor >>>>> changes. The changes I made was changing class_name to >>>>> _class_name and cp to _cp, and not more than that. To see these >>>>> changes, you'll have to look at before/after code and not the >>>>> diffs. I also tried moving this layout_fields() function around >>>>> to it wouldn't false match but I wanted to keep it next to >>>>> parseClassFile() and not move it too far away. >>>>> >>>>> Tested with runThese jck, jck8 lang and vm, NSK vm.quick.testlist, >>>>> java/lang/invoke jtreg tests and java/lang/instrument jtreg tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> >> From zhengyu.gu at oracle.com Mon Mar 11 11:21:49 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 11 Mar 2013 14:21:49 -0400 Subject: Review Request: 8009298 and 8009777 Message-ID: <513E20BD.3050800@oracle.com> 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT 8009777: NMT: add new NMT dcmd to control auto shutdown option The two are related. The change is to add an addition VM diagnostic command-line option "AutoShutdownNMT". By default, native memory tracking runtime shuts itself down under stress situation, and release memory to allow JVM continue running. But this feature can be undesirable when this is the situation we really want to know what's happening to JVM memory usage, even that means that we need to sacrifice JVM performance. When AutoShutdownNMT is set to false, NMT will try its best to stay alive by slowing down threads calling memory allocation/de-allocation. Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ Tests: The test case is special version of runThese, it uses 12 threads to load/unloading classes without executing any tests. Following two memory usage graphs show the different behavior with AutoShutdownNMT on/off. AutoShutdownNMT = true http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png The steep drop in memory usage was result of shutting down of native memory tracking. AutoShutdownNMT = false http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png The steep dig was result of class unloading. Thanks, -Zhengyu From jon.masamitsu at oracle.com Mon Mar 11 11:46:19 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 11:46:19 -0700 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513E1B0B.9070902@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> <513A800E.6030902@oracle.com> <513B4EDB.9060509@oracle.com> <513E17C2.3020602@oracle.com> <513E1B0B.9070902@oracle.com> Message-ID: <513E267B.9050702@oracle.com> Coleen, Looks good. Humanity will thank you for the refactoring of parseClassFile() as much as you did. Jon On 03/11/13 10:57, Coleen Phillimore wrote: > On 3/11/2013 1:43 PM, Jon Masamitsu wrote: >> >> >> On 03/09/13 07:01, Coleen Phillmore wrote: >>> >>> Hi Jon, >>> >>> Thank you for starting to look at this. The huge number of diffs >>> in classFileParser.cpp is because I moved the code that laid out >>> fields and diff matches oddly so it looks like I changed a lot more >>> than I did. I should have done this in the first place, but here >>> are the changes I made without moving layout_fields. I'll move it >>> back (and remove the fac and parsed_allocations copying) after the >>> review. >>> >>> http://cr.openjdk.java.net/~coleenp/8003419_small/ >>> >>> This is much easier to read! >> >> Thanks. This helps. >> >> The description for apply_parsed_class_metadata() is >> >> *+ // Transfer ownership of metadata allocated to the InstanceKlass. >> >> When apply_parsed_class_metadata() all the metadata for >> the Klass has been allocated and is hanging off the >> ClassFileParser? > > Yes. > Coleen > >> >> Jon >> >> * >> >> >> >>> >>> On 3/8/2013 7:19 PM, Jon Masamitsu wrote: >>>> Coleen, >>>> >>>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html >>>> >>>> >>>> *+ // metadata created before the instance klass is created. >>>> Must be* >>>> *+ // deallocated if classfile parsing returns an error.* >>>> >>>> Could this also have said >>>> >>>> "Must be deallocated if not transferred to the InstanceKlass upon >>>> sucessful class loading >>>> in which case these pointers have been set to NULL." >>> >>> I changed the comment (adding a 'c' to it) to yours. >>>> >>>> At first I didn't understand why the destructor didn't always >>>> deallocate the >>>> metadata. >>>> >>>> Can all the fields with pointers to metadata be grouped together >>>> and in the destructor iterate through the pointers to see that they >>>> are >>>> all NULL? Worth doing to catch leaks? >>> >>> The deallocation uses template functions for the types of each >>> pointer so iterating through pointers won't work. >>>> >>>> >>>> This file just had so many changes in it I quickly bogged down. I'll >>>> try again later. So far only >>>> >>>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>> >>>> >>>> 2991 // Assign allocations if needed >>>> >>>> allocations or annotations? >>>> >>> >>> Annotations, fixed. >>>> Can you make this unsigned? >>>> >>>> 3288 int map_count = _super_klass->nonstatic_oop_map_count(); >>>> >>> >>> Yes, I changed it. The field nonstatic_oop_map_count is unsigned. >>> >>> Thanks! >>> Coleen >>> >>>> >>>> >>>> Jon >>>> >>>> >>>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>>> >>>>> Resend to hotspot-dev. I don't think anyone reads >>>>> hotspot-runtime-dev anymore. >>>>> Please review!! >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>>>>> Summary: Store metadata on ClassFileParser instance to be cleaned >>>>>> up by destructor. This enabled some refactoring of the enormous >>>>>> parseClassFile function. >>>>>> >>>>>> Note: I moved out code that lays out the java object into it's >>>>>> own function, but the diffs made it look like I made more than >>>>>> minor changes. The changes I made was changing class_name to >>>>>> _class_name and cp to _cp, and not more than that. To see these >>>>>> changes, you'll have to look at before/after code and not the >>>>>> diffs. I also tried moving this layout_fields() function around >>>>>> to it wouldn't false match but I wanted to keep it next to >>>>>> parseClassFile() and not move it too far away. >>>>>> >>>>>> Tested with runThese jck, jck8 lang and vm, NSK >>>>>> vm.quick.testlist, java/lang/invoke jtreg tests and >>>>>> java/lang/instrument jtreg tests. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>> >>> > From coleen.phillimore at oracle.com Mon Mar 11 13:28:47 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Mar 2013 16:28:47 -0400 Subject: Review request (L) 8003419: NPG: Clean up metadata created during class loading if failure In-Reply-To: <513E267B.9050702@oracle.com> References: <51350056.7020805@oracle.com> <513647E6.3080908@oracle.com> <513A800E.6030902@oracle.com> <513B4EDB.9060509@oracle.com> <513E17C2.3020602@oracle.com> <513E1B0B.9070902@oracle.com> <513E267B.9050702@oracle.com> Message-ID: <513E3E7F.8030508@oracle.com> On 3/11/2013 2:46 PM, Jon Masamitsu wrote: > Coleen, > > Looks good. Thank you, Jon! > > Humanity will thank you for the refactoring > of parseClassFile() as much as you did. I hope the C++ compiler likes it too. Thanks, Coleen > > Jon > > On 03/11/13 10:57, Coleen Phillimore wrote: >> On 3/11/2013 1:43 PM, Jon Masamitsu wrote: >>> >>> >>> On 03/09/13 07:01, Coleen Phillmore wrote: >>>> >>>> Hi Jon, >>>> >>>> Thank you for starting to look at this. The huge number of diffs >>>> in classFileParser.cpp is because I moved the code that laid out >>>> fields and diff matches oddly so it looks like I changed a lot more >>>> than I did. I should have done this in the first place, but here >>>> are the changes I made without moving layout_fields. I'll move it >>>> back (and remove the fac and parsed_allocations copying) after the >>>> review. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8003419_small/ >>>> >>>> This is much easier to read! >>> >>> Thanks. This helps. >>> >>> The description for apply_parsed_class_metadata() is >>> >>> *+ // Transfer ownership of metadata allocated to the InstanceKlass. >>> >>> When apply_parsed_class_metadata() all the metadata for >>> the Klass has been allocated and is hanging off the >>> ClassFileParser? >> >> Yes. >> Coleen >> >>> >>> Jon >>> >>> * >>> >>> >>> >>>> >>>> On 3/8/2013 7:19 PM, Jon Masamitsu wrote: >>>>> Coleen, >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.hpp.udiff.html >>>>> >>>>> >>>>> *+ // metadata created before the instance klass is created. >>>>> Must be* >>>>> *+ // deallocated if classfile parsing returns an error.* >>>>> >>>>> Could this also have said >>>>> >>>>> "Must be deallocated if not transferred to the InstanceKlass upon >>>>> sucessful class loading >>>>> in which case these pointers have been set to NULL." >>>> >>>> I changed the comment (adding a 'c' to it) to yours. >>>>> >>>>> At first I didn't understand why the destructor didn't always >>>>> deallocate the >>>>> metadata. >>>>> >>>>> Can all the fields with pointers to metadata be grouped together >>>>> and in the destructor iterate through the pointers to see that >>>>> they are >>>>> all NULL? Worth doing to catch leaks? >>>> >>>> The deallocation uses template functions for the types of each >>>> pointer so iterating through pointers won't work. >>>>> >>>>> >>>>> This file just had so many changes in it I quickly bogged down. I'll >>>>> try again later. So far only >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8003419/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>>> >>>>> >>>>> 2991 // Assign allocations if needed >>>>> >>>>> allocations or annotations? >>>>> >>>> >>>> Annotations, fixed. >>>>> Can you make this unsigned? >>>>> >>>>> 3288 int map_count = _super_klass->nonstatic_oop_map_count(); >>>>> >>>> >>>> Yes, I changed it. The field nonstatic_oop_map_count is unsigned. >>>> >>>> Thanks! >>>> Coleen >>>> >>>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/5/2013 11:30 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Resend to hotspot-dev. I don't think anyone reads >>>>>> hotspot-runtime-dev anymore. >>>>>> Please review!! >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 03/04/2013 03:13 PM, Coleen Phillimore wrote: >>>>>>> Summary: Store metadata on ClassFileParser instance to be >>>>>>> cleaned up by destructor. This enabled some refactoring of the >>>>>>> enormous parseClassFile function. >>>>>>> >>>>>>> Note: I moved out code that lays out the java object into it's >>>>>>> own function, but the diffs made it look like I made more than >>>>>>> minor changes. The changes I made was changing class_name to >>>>>>> _class_name and cp to _cp, and not more than that. To see >>>>>>> these changes, you'll have to look at before/after code and not >>>>>>> the diffs. I also tried moving this layout_fields() function >>>>>>> around to it wouldn't false match but I wanted to keep it next >>>>>>> to parseClassFile() and not move it too far away. >>>>>>> >>>>>>> Tested with runThese jck, jck8 lang and vm, NSK >>>>>>> vm.quick.testlist, java/lang/invoke jtreg tests and >>>>>>> java/lang/instrument jtreg tests. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003419/ >>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003419 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >> From joseph.provino at oracle.com Mon Mar 11 15:48:16 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 11 Mar 2013 18:48:16 -0400 Subject: review request -- JDK-8009835 - Only produce a warning when -Xshare:auto is explicitly requested Message-ID: <513E5F30.20601@oracle.com> Webrev is here: http://cr.openjdk.java.net/~jprovino/8009835/webrev.00 thanks. joe From coleen.phillimore at oracle.com Mon Mar 11 16:02:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Mar 2013 19:02:25 -0400 Subject: review request -- JDK-8009835 - Only produce a warning when -Xshare:auto is explicitly requested In-Reply-To: <513E5F30.20601@oracle.com> References: <513E5F30.20601@oracle.com> Message-ID: <513E6281.6080204@oracle.com> On 3/11/2013 6:48 PM, JOSEPH PROVINO wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/8009835/webrev.00 > > thanks. > > joe This looks good. Coleen From david.holmes at oracle.com Mon Mar 11 19:52:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 12:52:23 +1000 Subject: review request -- JDK-8009835 - Only produce a warning when -Xshare:auto is explicitly requested In-Reply-To: <513E6281.6080204@oracle.com> References: <513E5F30.20601@oracle.com> <513E6281.6080204@oracle.com> Message-ID: <513E9867.2020408@oracle.com> On 12/03/2013 9:02 AM, Coleen Phillimore wrote: > On 3/11/2013 6:48 PM, JOSEPH PROVINO wrote: >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8009835/webrev.00 >> >> thanks. >> >> joe > > This looks good. I concur :) David > Coleen From volker.simonis at gmail.com Tue Mar 12 01:40:04 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Mar 2013 09:40:04 +0100 Subject: hg: hsx/hsx24/hotspot: 2 new changesets In-Reply-To: <20130220163355.2096847C07@hg.openjdk.java.net> References: <20130220163355.2096847C07@hg.openjdk.java.net> Message-ID: Hi, I have several questions regarding these changes: - why have these two changes been submitted two times? - I always thought that a unique bug ID is required for a successful push? Doesn't this apply to the hsxXX repos? - why has this change been submit to (and only to) the hsx24 repository (I thought hotspot changes need to go to hsx first before they can be downported to hsxXX)? Thank you and best regards, Volker On Wed, Feb 20, 2013 at 5:33 PM, wrote: > Changeset: 4eca232ca0c6 > Author: nloodin > Date: 2013-02-20 11:24 +0100 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4eca232ca0c6 > > 8007804: Need to be able to access Performance counter by name from JVM > Reviewed-by: dholmes, sla, sspitsyn > > ! src/share/vm/runtime/perfData.cpp > ! src/share/vm/runtime/perfData.hpp > > Changeset: 32ff8194b6d4 > Author: nloodin > Date: 2013-02-20 06:25 -0800 > URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/32ff8194b6d4 > > Merge > > From nils.loodin at oracle.com Tue Mar 12 01:52:14 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 12 Mar 2013 09:52:14 +0100 Subject: hg: hsx/hsx24/hotspot: 2 new changesets In-Reply-To: References: <20130220163355.2096847C07@hg.openjdk.java.net> Message-ID: <513EECBE.4050208@oracle.com> On 03/12/2013 09:40 AM, Volker Simonis wrote: > Hi, > > I have several questions regarding these changes: > > - why have these two changes been submitted two times? That's a good question, for which I do not have the answer. The submittal system we have should make this impossible. > - I always thought that a unique bug ID is required for a successful > push? Doesn't this apply to the hsxXX repos? I think this particular check for some reason has been disabled in hsx24. I think Alejandro Murilo might know more about this. > - why has this change been submit to (and only to) the hsx24 > repository (I thought hotspot changes need to go to hsx first before > they can be downported to hsxXX)? That's the general idea, although there are exceptions to this. Anyway, this issue was found as soon at is came in, and I think Alejandro has worked around it. Regards, Nils Loodin > > Thank you and best regards, > Volker > > > On Wed, Feb 20, 2013 at 5:33 PM, wrote: >> Changeset: 4eca232ca0c6 >> Author: nloodin >> Date: 2013-02-20 11:24 +0100 >> URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4eca232ca0c6 >> >> 8007804: Need to be able to access Performance counter by name from JVM >> Reviewed-by: dholmes, sla, sspitsyn >> >> ! src/share/vm/runtime/perfData.cpp >> ! src/share/vm/runtime/perfData.hpp >> >> Changeset: 32ff8194b6d4 >> Author: nloodin >> Date: 2013-02-20 06:25 -0800 >> URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/32ff8194b6d4 >> >> Merge >> >> From frederic.parain at oracle.com Tue Mar 12 03:10:44 2013 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 12 Mar 2013 11:10:44 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <513EFF24.90504@oracle.com> Vote: yes Fred On 02/26/13 09:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- 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 Tue Mar 12 05:36:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 12:36:08 +0000 Subject: Request for review- RFE 8005716 In-Reply-To: <513DFA1D.1000902@oracle.com> References: <51367A43.1060606@oracle.com> <513748D4.3080803@oracle.com> <5138C22B.5070803@oracle.com> <5138FDA7.6040108@oracle.com> <51394B5C.2090306@oracle.com> <513DDECA.7090003@oracle.com> <513DFA1D.1000902@oracle.com> Message-ID: <513F2138.30102@oracle.com> On 11/03/2013 15:37, BILL PITTORE wrote: > On 3/11/2013 9:40 AM, Alan Bateman wrote: >> On 08/03/2013 02:22, BILL PITTORE wrote: >>> Moved the string allocation into buildJniFunctionName as Alan >>> suggested. Built and tested on windows and linux. Updated the webrev: >>> >>> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ >>> >>> >>> bill >> I see this updates the method descriptions to take on board Jeremy's >> comment on the possibility of the library being statically linked >> with the main executable with or without the VM. To be complete, I >> think this will require an update to the UnstatisfiedLinkError >> description too. >> >> Thanks for moving the sizing/allocation of the function name into >> buildJniFunctionName as that is cleaner and safer. Is FILENAME_MAX >> really the right limit to impose? > Maybe JVM_MAXPATHLEN is the better choice. As it's a symbol rather than a file path then it's probably not right either. I guess the question is whether a limit needs to be checked here or not. -Alan. From joseph.provino at oracle.com Tue Mar 12 08:36:00 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Tue, 12 Mar 2013 11:36:00 -0400 Subject: review request -- 8009904 jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm Message-ID: <513F4B60.7000007@oracle.com> The webrev is here: http://cr.openjdk.java.net/~jprovino/8009904/webrev.00 The only change is to hotspot/make/excludeSrc.make Thanks. joe From serguei.spitsyn at oracle.com Tue Mar 12 09:54:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Mar 2013 09:54:30 -0700 Subject: review request -- 8009904 jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm In-Reply-To: <513F4B60.7000007@oracle.com> References: <513F4B60.7000007@oracle.com> Message-ID: <513F5DC6.4090808@oracle.com> The fix is good. Thanks, Serguei On 3/12/13 8:36 AM, JOSEPH PROVINO wrote: > The webrev is here: > > http://cr.openjdk.java.net/~jprovino/8009904/webrev.00 > > The only change is to hotspot/make/excludeSrc.make > > Thanks. > > joe From jesper.wilhelmsson at oracle.com Tue Mar 12 11:58:56 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 12 Mar 2013 18:58:56 +0000 Subject: hg: hsx/hsx24/hotspot: 8007003: ParNew sends the heap summary too early Message-ID: <20130312185901.B85BA480B7@hg.openjdk.java.net> Changeset: e41e48824311 Author: jwilhelm Date: 2013-03-12 16:28 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e41e48824311 8007003: ParNew sends the heap summary too early Summary: Send the event after the early exit Reviewed-by: ehelin, brutisso ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp From kevin.walls at oracle.com Tue Mar 12 18:16:42 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Wed, 13 Mar 2013 01:16:42 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130313011649.BABC4480CC@hg.openjdk.java.net> Changeset: ca064de1c4c6 Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ca064de1c4c6 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 739a10899202 Author: kevinw Date: 2013-03-12 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/739a10899202 Merge From david.holmes at oracle.com Wed Mar 13 02:36:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 19:36:29 +1000 Subject: review request -- 8009904 jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm In-Reply-To: <513F4B60.7000007@oracle.com> References: <513F4B60.7000007@oracle.com> Message-ID: <5140489D.4000902@oracle.com> Looks fine Joe. Thanks, David On 13/03/2013 1:36 AM, JOSEPH PROVINO wrote: > The webrev is here: > > http://cr.openjdk.java.net/~jprovino/8009904/webrev.00 > > The only change is to hotspot/make/excludeSrc.make > > Thanks. > > joe From rickard.backman at oracle.com Wed Mar 13 02:50:31 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 10:50:31 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes Message-ID: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> Hi all, I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. Step 1) * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. * The #include os_name.hpp inside the class definition is moved to before the definition of class os. * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. * Adds a typedef osCurrent pd; inside the os class. Step 2) * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. Step 3) * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. * Changes #includes of os__ into #include "os_cpu" * Adds a typedef osCpu cpu; inside the os class. Step 4) * Renames os_posix to os_xnix (xnix is *nix). * Renames os_.ext to os_family.ext * Includes are changed from: #ifdef TARGET_OS_FAMILY_linux # include "os_linux.hpp" #endif #ifdef TARGET_OS_FAMILY_solaris # include "os_solaris.hpp" #endif #ifdef TARGET_OS_FAMILY_windows # include "os_windows.hpp" #endif #ifdef TARGET_OS_FAMILY_bsd # include "os_bsd.hpp" #endif to: #include "os_family.hpp" I'll try to summarize the final result the way it would look for solaris_sparc: There are three classes: osSolaris, osSolarisSparc and os. These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. Inside the os class we now typedef osCurrent to pd and osCpu to cpu. This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: doSomething() { os::pd::setup(); do_something(); os::pd::close(); } This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. To show the layout of the files: file: os_family.hpp class osSolaris { }; typedef osSolaris osCurrent; file: os_cpu.hpp class osSolarisSparc { }; typedef osSolarisSparc osCpu; file: os.hpp class os { typedef osCpu cpu; typedef osCurrent pd; }; Webrevs: http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ Thanks /R From david.holmes at oracle.com Wed Mar 13 03:33:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 20:33:10 +1000 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> Message-ID: <514055E6.9050107@oracle.com> Hi Rickard, An initial comment on your description here: > There are three classes: osSolaris, osSolarisSparc and os. > These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. > Inside the os class we now typedef osCurrent to pd and osCpu to cpu. > This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: > > doSomething() { > os::pd::setup(); > do_something(); > os::pd::close(); > } I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". Cheers, David On 13/03/2013 7:50 PM, Rickard B?ckman wrote: > Hi all, > > I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. > > The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. > > Step 1) > * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. > * The #include os_name.hpp inside the class definition is moved to before the definition of class os. > * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. > * Adds a typedef osCurrent pd; inside the os class. > > Step 2) > * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. > > Step 3) > * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. > * Changes #includes of os__ into #include "os_cpu" > * Adds a typedef osCpu cpu; inside the os class. > > Step 4) > * Renames os_posix to os_xnix (xnix is *nix). > * Renames os_.ext to os_family.ext > * Includes are changed from: > > #ifdef TARGET_OS_FAMILY_linux > # include "os_linux.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "os_solaris.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "os_windows.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "os_bsd.hpp" > #endif > > to: > > #include "os_family.hpp" > > > I'll try to summarize the final result the way it would look for solaris_sparc: > > There are three classes: osSolaris, osSolarisSparc and os. > These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. > Inside the os class we now typedef osCurrent to pd and osCpu to cpu. > This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: > > doSomething() { > os::pd::setup(); > do_something(); > os::pd::close(); > } > > This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. > > it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. > > To show the layout of the files: > > file: os_family.hpp > class osSolaris { > }; > > typedef osSolaris osCurrent; > > file: os_cpu.hpp > class osSolarisSparc { > }; > > typedef osSolarisSparc osCpu; > > file: os.hpp > class os { > typedef osCpu cpu; > typedef osCurrent pd; > }; > > Webrevs: > http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ > http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ > http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ > http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ > > Thanks > /R > From rickard.backman at oracle.com Wed Mar 13 04:41:09 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 12:41:09 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <514055E6.9050107@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> Message-ID: David, On Mar 13, 2013, at 11:33 AM, David Holmes wrote: > Hi Rickard, > > An initial comment on your description here: > >> There are three classes: osSolaris, osSolarisSparc and os. >> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >> >> doSomething() { >> os::pd::setup(); >> do_something(); >> os::pd::close(); >> } > > I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". So maybe the example here was a bit bad. Maybe this makes more sense: osXnix::suspend_thread(thread) { ... os::pd::signal_notify(thread); ? } You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. Another example taken from os::Bsd void os::Bsd::hotspot_sigmask(Thread* thread) { //Save caller's signal mask before setting VM signal mask sigset_t caller_sigmask; pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); OSThread* osthread = thread->osthread(); osthread->set_caller_sigmask(caller_sigmask); pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); if (!ReduceSignalUsage) { if (thread->is_VM_thread()) { // Only the VM thread handles BREAK_SIGNAL ... pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); } else { // ... all other threads block BREAK_SIGNAL pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); } } } could be replaced by an: void osXnix::hotspot_sigmask(Thread *thread) { sigset_t caller_sigmask; os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); ? os::pd::thread_sigmask(?); ? } thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. I just think that this change is large enough as it is. Further improvements are always possible. Thanks /R > > Cheers, > David > > On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >> Hi all, >> >> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >> >> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >> >> Step 1) >> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >> * Adds a typedef osCurrent pd; inside the os class. >> >> Step 2) >> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >> >> Step 3) >> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >> * Changes #includes of os__ into #include "os_cpu" >> * Adds a typedef osCpu cpu; inside the os class. >> >> Step 4) >> * Renames os_posix to os_xnix (xnix is *nix). >> * Renames os_.ext to os_family.ext >> * Includes are changed from: >> >> #ifdef TARGET_OS_FAMILY_linux >> # include "os_linux.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_solaris >> # include "os_solaris.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_windows >> # include "os_windows.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_bsd >> # include "os_bsd.hpp" >> #endif >> >> to: >> >> #include "os_family.hpp" >> >> >> I'll try to summarize the final result the way it would look for solaris_sparc: >> >> There are three classes: osSolaris, osSolarisSparc and os. >> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >> >> doSomething() { >> os::pd::setup(); >> do_something(); >> os::pd::close(); >> } >> >> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >> >> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >> >> To show the layout of the files: >> >> file: os_family.hpp >> class osSolaris { >> }; >> >> typedef osSolaris osCurrent; >> >> file: os_cpu.hpp >> class osSolarisSparc { >> }; >> >> typedef osSolarisSparc osCpu; >> >> file: os.hpp >> class os { >> typedef osCpu cpu; >> typedef osCurrent pd; >> }; >> >> Webrevs: >> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >> >> Thanks >> /R >> From david.holmes at oracle.com Wed Mar 13 05:57:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 22:57:04 +1000 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> Message-ID: <514077A0.2010703@oracle.com> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: > David, > > On Mar 13, 2013, at 11:33 AM, David Holmes wrote: > >> Hi Rickard, >> >> An initial comment on your description here: >> >>> There are three classes: osSolaris, osSolarisSparc and os. >>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>> >>> doSomething() { >>> os::pd::setup(); >>> do_something(); >>> os::pd::close(); >>> } >> >> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". > > So maybe the example here was a bit bad. Maybe this makes more sense: > > osXnix::suspend_thread(thread) { > ... > os::pd::signal_notify(thread); > ? > } > > You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. David > Another example taken from os::Bsd > > void os::Bsd::hotspot_sigmask(Thread* thread) { > > //Save caller's signal mask before setting VM signal mask > sigset_t caller_sigmask; > pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); > > OSThread* osthread = thread->osthread(); > osthread->set_caller_sigmask(caller_sigmask); > > pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); > > if (!ReduceSignalUsage) { > if (thread->is_VM_thread()) { > // Only the VM thread handles BREAK_SIGNAL ... > pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); > } else { > // ... all other threads block BREAK_SIGNAL > pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); > } > } > } > > could be replaced by an: > > void osXnix::hotspot_sigmask(Thread *thread) { > sigset_t caller_sigmask; > os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); > ? > os::pd::thread_sigmask(?); > ? > } > > thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. > > I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. > I just think that this change is large enough as it is. Further improvements are always possible. > > Thanks > /R > > >> >> Cheers, >> David >> >> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>> Hi all, >>> >>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>> >>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>> >>> Step 1) >>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>> * Adds a typedef osCurrent pd; inside the os class. >>> >>> Step 2) >>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>> >>> Step 3) >>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>> * Changes #includes of os__ into #include "os_cpu" >>> * Adds a typedef osCpu cpu; inside the os class. >>> >>> Step 4) >>> * Renames os_posix to os_xnix (xnix is *nix). >>> * Renames os_.ext to os_family.ext >>> * Includes are changed from: >>> >>> #ifdef TARGET_OS_FAMILY_linux >>> # include "os_linux.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_solaris >>> # include "os_solaris.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_windows >>> # include "os_windows.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_bsd >>> # include "os_bsd.hpp" >>> #endif >>> >>> to: >>> >>> #include "os_family.hpp" >>> >>> >>> I'll try to summarize the final result the way it would look for solaris_sparc: >>> >>> There are three classes: osSolaris, osSolarisSparc and os. >>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>> >>> doSomething() { >>> os::pd::setup(); >>> do_something(); >>> os::pd::close(); >>> } >>> >>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>> >>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>> >>> To show the layout of the files: >>> >>> file: os_family.hpp >>> class osSolaris { >>> }; >>> >>> typedef osSolaris osCurrent; >>> >>> file: os_cpu.hpp >>> class osSolarisSparc { >>> }; >>> >>> typedef osSolarisSparc osCpu; >>> >>> file: os.hpp >>> class os { >>> typedef osCpu cpu; >>> typedef osCurrent pd; >>> }; >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>> >>> Thanks >>> /R >>> > From rickard.backman at oracle.com Wed Mar 13 06:11:54 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 14:11:54 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <514077A0.2010703@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> Message-ID: David, On Mar 13, 2013, at 1:57 PM, David Holmes wrote: > On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >> David, >> >> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >> >>> Hi Rickard, >>> >>> An initial comment on your description here: >>> >>>> There are three classes: osSolaris, osSolarisSparc and os. >>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>> >>>> doSomething() { >>>> os::pd::setup(); >>>> do_something(); >>>> os::pd::close(); >>>> } >>> >>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >> >> So maybe the example here was a bit bad. Maybe this makes more sense: >> >> osXnix::suspend_thread(thread) { >> ... >> os::pd::signal_notify(thread); >> ? >> } >> >> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. > > But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. os:: is still the main interface to os things. In my example above we would have had an os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. os::suspend_thread() would look like: { os::pd::suspend_thread(); } instead of having 4 different implementations of suspend_thread, we would now have 2. Hope that makes things clearer. Thanks /R > > David > >> Another example taken from os::Bsd >> >> void os::Bsd::hotspot_sigmask(Thread* thread) { >> >> //Save caller's signal mask before setting VM signal mask >> sigset_t caller_sigmask; >> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >> >> OSThread* osthread = thread->osthread(); >> osthread->set_caller_sigmask(caller_sigmask); >> >> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >> >> if (!ReduceSignalUsage) { >> if (thread->is_VM_thread()) { >> // Only the VM thread handles BREAK_SIGNAL ... >> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >> } else { >> // ... all other threads block BREAK_SIGNAL >> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >> } >> } >> } >> >> could be replaced by an: >> >> void osXnix::hotspot_sigmask(Thread *thread) { >> sigset_t caller_sigmask; >> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >> ? >> os::pd::thread_sigmask(?); >> ? >> } >> >> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >> >> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >> I just think that this change is large enough as it is. Further improvements are always possible. >> >> Thanks >> /R >> >> >>> >>> Cheers, >>> David >>> >>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>> >>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>> >>>> Step 1) >>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>> * Adds a typedef osCurrent pd; inside the os class. >>>> >>>> Step 2) >>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>> >>>> Step 3) >>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>> * Changes #includes of os__ into #include "os_cpu" >>>> * Adds a typedef osCpu cpu; inside the os class. >>>> >>>> Step 4) >>>> * Renames os_posix to os_xnix (xnix is *nix). >>>> * Renames os_.ext to os_family.ext >>>> * Includes are changed from: >>>> >>>> #ifdef TARGET_OS_FAMILY_linux >>>> # include "os_linux.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_solaris >>>> # include "os_solaris.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_windows >>>> # include "os_windows.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_bsd >>>> # include "os_bsd.hpp" >>>> #endif >>>> >>>> to: >>>> >>>> #include "os_family.hpp" >>>> >>>> >>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>> >>>> There are three classes: osSolaris, osSolarisSparc and os. >>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>> >>>> doSomething() { >>>> os::pd::setup(); >>>> do_something(); >>>> os::pd::close(); >>>> } >>>> >>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>> >>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>> >>>> To show the layout of the files: >>>> >>>> file: os_family.hpp >>>> class osSolaris { >>>> }; >>>> >>>> typedef osSolaris osCurrent; >>>> >>>> file: os_cpu.hpp >>>> class osSolarisSparc { >>>> }; >>>> >>>> typedef osSolarisSparc osCpu; >>>> >>>> file: os.hpp >>>> class os { >>>> typedef osCpu cpu; >>>> typedef osCurrent pd; >>>> }; >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>> >>>> Thanks >>>> /R >>>> >> From coleen.phillimore at oracle.com Wed Mar 13 06:22:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 13 Mar 2013 09:22:12 -0400 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <514077A0.2010703@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> Message-ID: <51407D84.8090102@oracle.com> On 3/13/2013 8:57 AM, David Holmes wrote: > On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >> David, >> >> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >> >>> Hi Rickard, >>> >>> An initial comment on your description here: >>> >>>> There are three classes: osSolaris, osSolarisSparc and os. >>>> These are tried together through a couple of typedefs. osSolaris is >>>> typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>> This way we can now access things that was previously accessed >>>> through os::Solaris::some_method like: os::pd::some_method. That >>>> helps if we want to write some code that would be common for a >>>> couple of platforms, using an api through pd like: >>>> >>>> doSomething() { >>>> os::pd::setup(); >>>> do_something(); >>>> os::pd::close(); >>>> } >>> >>> I don't think the "pd" makes sense because you have to know what the >>> "pd" actually is. In old terms an os::Solaris method can call >>> another os::Solaris method because it knows it is there. If "pd" is >>> common somehow (say pthreads functionality) then that commonality >>> has to be named eg os::pthreads, because there might be another >>> commonality related to some other aspect of functionality (perhaps >>> Dtrace), so they can't both be called "pd". >> >> So maybe the example here was a bit bad. Maybe this makes more sense: >> >> osXnix::suspend_thread(thread) { >> ... >> os::pd::signal_notify(thread); >> ? >> } >> >> You still have to know that pd is an interface for one os >> platform-dependent API. signal_notify() in this example would be >> implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. >> Windows wouldn't need one. > > But that seems more awkward than what we have now. Now we have > os::signal_notify() which is implemented differently for > solaris/linux/bsd. That specialization is done via the compile-time > include mechanism. With what you suggest the methods that call things > like signal_notify now have to know that they are implemented > differently on different platforms whereas currently they do not need > to know that. So this is a good argument for simply promoting most/many/all of these pd functions to os.hpp, have the implementation be in os_.cpp and lose the fact that they are osBsd/osLinux/osWindows class concept. Is this possible? Would it make the os:: class/namespace too large? Could we still get rid of the #includes in the middle of the class declaration? Thanks, Coleen > > David > >> Another example taken from os::Bsd >> >> void os::Bsd::hotspot_sigmask(Thread* thread) { >> >> //Save caller's signal mask before setting VM signal mask >> sigset_t caller_sigmask; >> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >> >> OSThread* osthread = thread->osthread(); >> osthread->set_caller_sigmask(caller_sigmask); >> >> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >> >> if (!ReduceSignalUsage) { >> if (thread->is_VM_thread()) { >> // Only the VM thread handles BREAK_SIGNAL ... >> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >> } else { >> // ... all other threads block BREAK_SIGNAL >> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >> } >> } >> } >> >> could be replaced by an: >> >> void osXnix::hotspot_sigmask(Thread *thread) { >> sigset_t caller_sigmask; >> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >> ? >> os::pd::thread_sigmask(?); >> ? >> } >> >> thread_sigmask would be pthread_sigmask for Bsd, Linux and >> thr_setsigmask on Solaris. >> >> I agree that having yet another level of grouping like >> os::signals::sigmask() or os::threads::create_thread() might be a >> good idea. >> I just think that this change is large enough as it is. Further >> improvements are always possible. >> >> Thanks >> /R >> >> >>> >>> Cheers, >>> David >>> >>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> I've spent some time on trying to do some changes to (in my >>>> opinion) clean up the os_ files. >>>> >>>> The change is broken up into 4 web revs to make the changes easier >>>> to spot since it involves new files, renaming of files, etc. >>>> >>>> Step 1) >>>> * removes the os::Bsd, os::Linux, etc classes. They are >>>> replaced by classes osBsd, osLinux, osPosix (renamed in a later >>>> step), etc. >>>> * The #include os_name.hpp inside the class definition is moved >>>> to before the definition of class os. >>>> * Renaming users to the new osBsd, osSolaris, osWindows, >>>> osLinux, etc. >>>> * Adds a typedef osCurrent pd; inside the os class. >>>> >>>> Step 2) >>>> * Some methods existed in all or almost all >>>> os__.hpp, they were moved to os.hpp. >>>> >>>> Step 3) >>>> * Removes os__.hpp and replaces it with a >>>> os_cpu.hpp. A new os_cpu.cpp contains the implementations of those >>>> methods. >>>> * Changes #includes of os__ into #include "os_cpu" >>>> * Adds a typedef osCpu cpu; inside the os class. >>>> >>>> Step 4) >>>> * Renames os_posix to os_xnix (xnix is *nix). >>>> * Renames os_.ext to os_family.ext >>>> * Includes are changed from: >>>> >>>> #ifdef TARGET_OS_FAMILY_linux >>>> # include "os_linux.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_solaris >>>> # include "os_solaris.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_windows >>>> # include "os_windows.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_bsd >>>> # include "os_bsd.hpp" >>>> #endif >>>> >>>> to: >>>> >>>> #include "os_family.hpp" >>>> >>>> >>>> I'll try to summarize the final result the way it would look for >>>> solaris_sparc: >>>> >>>> There are three classes: osSolaris, osSolarisSparc and os. >>>> These are tried together through a couple of typedefs. osSolaris is >>>> typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>> This way we can now access things that was previously accessed >>>> through os::Solaris::some_method like: os::pd::some_method. That >>>> helps if we want to write some code that would be common for a >>>> couple of platforms, using an api through pd like: >>>> >>>> doSomething() { >>>> os::pd::setup(); >>>> do_something(); >>>> os::pd::close(); >>>> } >>>> >>>> This should enable us to move code from platform specific code >>>> (thread creation, signal handling, etc) that look very similar >>>> (Linux, Bsd, Solaris) into something else that utilizes APIs >>>> through os::pd or os::cpu. >>>> >>>> it enables us to have platform specific includes in what >>>> os_family.hpp (used to be os_linux.hpp) for platform specific >>>> things like semaphores. >>>> >>>> To show the layout of the files: >>>> >>>> file: os_family.hpp >>>> class osSolaris { >>>> }; >>>> >>>> typedef osSolaris osCurrent; >>>> >>>> file: os_cpu.hpp >>>> class osSolarisSparc { >>>> }; >>>> >>>> typedef osSolarisSparc osCpu; >>>> >>>> file: os.hpp >>>> class os { >>>> typedef osCpu cpu; >>>> typedef osCurrent pd; >>>> }; >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>> >>>> Thanks >>>> /R >>>> >> From coleen.phillimore at oracle.com Wed Mar 13 06:32:14 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 13 Mar 2013 09:32:14 -0400 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> Message-ID: <51407FDE.9070205@oracle.com> Your reply below made think maybe we should rename posix directories and files xnix. Coleen On 3/13/2013 9:11 AM, Rickard B?ckman wrote: > David, > > On Mar 13, 2013, at 1:57 PM, David Holmes wrote: > >> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>> David, >>> >>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>> >>>> Hi Rickard, >>>> >>>> An initial comment on your description here: >>>> >>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>> >>>>> doSomething() { >>>>> os::pd::setup(); >>>>> do_something(); >>>>> os::pd::close(); >>>>> } >>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>> So maybe the example here was a bit bad. Maybe this makes more sense: >>> >>> osXnix::suspend_thread(thread) { >>> ... >>> os::pd::signal_notify(thread); >>> ? >>> } >>> >>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. > Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). > > That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. > > os:: is still the main interface to os things. In my example above we would have had an > os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. > os::suspend_thread() would look like: > { > os::pd::suspend_thread(); > } > > instead of having 4 different implementations of suspend_thread, we would now have 2. > > Hope that makes things clearer. > > Thanks > /R > >> David >> >>> Another example taken from os::Bsd >>> >>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>> >>> //Save caller's signal mask before setting VM signal mask >>> sigset_t caller_sigmask; >>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>> >>> OSThread* osthread = thread->osthread(); >>> osthread->set_caller_sigmask(caller_sigmask); >>> >>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>> >>> if (!ReduceSignalUsage) { >>> if (thread->is_VM_thread()) { >>> // Only the VM thread handles BREAK_SIGNAL ... >>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>> } else { >>> // ... all other threads block BREAK_SIGNAL >>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>> } >>> } >>> } >>> >>> could be replaced by an: >>> >>> void osXnix::hotspot_sigmask(Thread *thread) { >>> sigset_t caller_sigmask; >>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>> ? >>> os::pd::thread_sigmask(?); >>> ? >>> } >>> >>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>> >>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>> I just think that this change is large enough as it is. Further improvements are always possible. >>> >>> Thanks >>> /R >>> >>> >>>> Cheers, >>>> David >>>> >>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>> Hi all, >>>>> >>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>> >>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>> >>>>> Step 1) >>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>> >>>>> Step 2) >>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>> >>>>> Step 3) >>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>> * Changes #includes of os__ into #include "os_cpu" >>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>> >>>>> Step 4) >>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>> * Renames os_.ext to os_family.ext >>>>> * Includes are changed from: >>>>> >>>>> #ifdef TARGET_OS_FAMILY_linux >>>>> # include "os_linux.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>> # include "os_solaris.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_windows >>>>> # include "os_windows.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>> # include "os_bsd.hpp" >>>>> #endif >>>>> >>>>> to: >>>>> >>>>> #include "os_family.hpp" >>>>> >>>>> >>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>> >>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>> >>>>> doSomething() { >>>>> os::pd::setup(); >>>>> do_something(); >>>>> os::pd::close(); >>>>> } >>>>> >>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>> >>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>> >>>>> To show the layout of the files: >>>>> >>>>> file: os_family.hpp >>>>> class osSolaris { >>>>> }; >>>>> >>>>> typedef osSolaris osCurrent; >>>>> >>>>> file: os_cpu.hpp >>>>> class osSolarisSparc { >>>>> }; >>>>> >>>>> typedef osSolarisSparc osCpu; >>>>> >>>>> file: os.hpp >>>>> class os { >>>>> typedef osCpu cpu; >>>>> typedef osCurrent pd; >>>>> }; >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>> >>>>> Thanks >>>>> /R >>>>> From rickard.backman at oracle.com Wed Mar 13 06:38:08 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 14:38:08 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <51407D84.8090102@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407D84.8090102@oracle.com> Message-ID: On Mar 13, 2013, at 2:22 PM, Coleen Phillmore wrote: > > On 3/13/2013 8:57 AM, David Holmes wrote: >> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>> David, >>> >>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>> >>>> Hi Rickard, >>>> >>>> An initial comment on your description here: >>>> >>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>> >>>>> doSomething() { >>>>> os::pd::setup(); >>>>> do_something(); >>>>> os::pd::close(); >>>>> } >>>> >>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>> >>> So maybe the example here was a bit bad. Maybe this makes more sense: >>> >>> osXnix::suspend_thread(thread) { >>> ... >>> os::pd::signal_notify(thread); >>> ? >>> } >>> >>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >> >> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. > > So this is a good argument for simply promoting most/many/all of these pd functions to os.hpp, have the implementation be in os_.cpp and lose the fact that they are osBsd/osLinux/osWindows class concept. Is this possible? Would it make the os:: class/namespace too large? Could we still get rid of the #includes in the middle of the class declaration? We could promote them, but we would get a new kind of problem: If there is a method declaration in os, does every os have to have an implementation of that method? It makes it harder to see what is considered platform dependent / not platform dependent. The includes could still be removed, one way to get there would be through converting the os class to a namespace. /R > > Thanks, > Coleen >> >> David >> >>> Another example taken from os::Bsd >>> >>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>> >>> //Save caller's signal mask before setting VM signal mask >>> sigset_t caller_sigmask; >>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>> >>> OSThread* osthread = thread->osthread(); >>> osthread->set_caller_sigmask(caller_sigmask); >>> >>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>> >>> if (!ReduceSignalUsage) { >>> if (thread->is_VM_thread()) { >>> // Only the VM thread handles BREAK_SIGNAL ... >>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>> } else { >>> // ... all other threads block BREAK_SIGNAL >>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>> } >>> } >>> } >>> >>> could be replaced by an: >>> >>> void osXnix::hotspot_sigmask(Thread *thread) { >>> sigset_t caller_sigmask; >>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>> ? >>> os::pd::thread_sigmask(?); >>> ? >>> } >>> >>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>> >>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>> I just think that this change is large enough as it is. Further improvements are always possible. >>> >>> Thanks >>> /R >>> >>> >>>> >>>> Cheers, >>>> David >>>> >>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>> Hi all, >>>>> >>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>> >>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>> >>>>> Step 1) >>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>> >>>>> Step 2) >>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>> >>>>> Step 3) >>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>> * Changes #includes of os__ into #include "os_cpu" >>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>> >>>>> Step 4) >>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>> * Renames os_.ext to os_family.ext >>>>> * Includes are changed from: >>>>> >>>>> #ifdef TARGET_OS_FAMILY_linux >>>>> # include "os_linux.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>> # include "os_solaris.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_windows >>>>> # include "os_windows.hpp" >>>>> #endif >>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>> # include "os_bsd.hpp" >>>>> #endif >>>>> >>>>> to: >>>>> >>>>> #include "os_family.hpp" >>>>> >>>>> >>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>> >>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>> >>>>> doSomething() { >>>>> os::pd::setup(); >>>>> do_something(); >>>>> os::pd::close(); >>>>> } >>>>> >>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>> >>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>> >>>>> To show the layout of the files: >>>>> >>>>> file: os_family.hpp >>>>> class osSolaris { >>>>> }; >>>>> >>>>> typedef osSolaris osCurrent; >>>>> >>>>> file: os_cpu.hpp >>>>> class osSolarisSparc { >>>>> }; >>>>> >>>>> typedef osSolarisSparc osCpu; >>>>> >>>>> file: os.hpp >>>>> class os { >>>>> typedef osCpu cpu; >>>>> typedef osCurrent pd; >>>>> }; >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>> >>>>> Thanks >>>>> /R >>>>> >>> > From rickard.backman at oracle.com Wed Mar 13 06:38:45 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 14:38:45 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <51407FDE.9070205@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> Message-ID: That is done in the step4 part of my webrev. :) /R On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: > > Your reply below made think maybe we should rename posix directories and files xnix. > Coleen > > On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >> David, >> >> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >> >>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>> David, >>>> >>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>> >>>>> Hi Rickard, >>>>> >>>>> An initial comment on your description here: >>>>> >>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>> >>>>>> doSomething() { >>>>>> os::pd::setup(); >>>>>> do_something(); >>>>>> os::pd::close(); >>>>>> } >>>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>>> So maybe the example here was a bit bad. Maybe this makes more sense: >>>> >>>> osXnix::suspend_thread(thread) { >>>> ... >>>> os::pd::signal_notify(thread); >>>> ? >>>> } >>>> >>>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >>> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. >> Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). >> >> That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. >> >> os:: is still the main interface to os things. In my example above we would have had an >> os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. >> os::suspend_thread() would look like: >> { >> os::pd::suspend_thread(); >> } >> >> instead of having 4 different implementations of suspend_thread, we would now have 2. >> >> Hope that makes things clearer. >> >> Thanks >> /R >> >>> David >>> >>>> Another example taken from os::Bsd >>>> >>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>> >>>> //Save caller's signal mask before setting VM signal mask >>>> sigset_t caller_sigmask; >>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>> >>>> OSThread* osthread = thread->osthread(); >>>> osthread->set_caller_sigmask(caller_sigmask); >>>> >>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>> >>>> if (!ReduceSignalUsage) { >>>> if (thread->is_VM_thread()) { >>>> // Only the VM thread handles BREAK_SIGNAL ... >>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>> } else { >>>> // ... all other threads block BREAK_SIGNAL >>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>> } >>>> } >>>> } >>>> >>>> could be replaced by an: >>>> >>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>> sigset_t caller_sigmask; >>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>> ? >>>> os::pd::thread_sigmask(?); >>>> ? >>>> } >>>> >>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>>> >>>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>> I just think that this change is large enough as it is. Further improvements are always possible. >>>> >>>> Thanks >>>> /R >>>> >>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>> Hi all, >>>>>> >>>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>>> >>>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>>> >>>>>> Step 1) >>>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>> >>>>>> Step 2) >>>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>>> >>>>>> Step 3) >>>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>> * Changes #includes of os__ into #include "os_cpu" >>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>> >>>>>> Step 4) >>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>> * Renames os_.ext to os_family.ext >>>>>> * Includes are changed from: >>>>>> >>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>> # include "os_linux.hpp" >>>>>> #endif >>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>> # include "os_solaris.hpp" >>>>>> #endif >>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>> # include "os_windows.hpp" >>>>>> #endif >>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>> # include "os_bsd.hpp" >>>>>> #endif >>>>>> >>>>>> to: >>>>>> >>>>>> #include "os_family.hpp" >>>>>> >>>>>> >>>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>>> >>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>> >>>>>> doSomething() { >>>>>> os::pd::setup(); >>>>>> do_something(); >>>>>> os::pd::close(); >>>>>> } >>>>>> >>>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>> >>>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>>> >>>>>> To show the layout of the files: >>>>>> >>>>>> file: os_family.hpp >>>>>> class osSolaris { >>>>>> }; >>>>>> >>>>>> typedef osSolaris osCurrent; >>>>>> >>>>>> file: os_cpu.hpp >>>>>> class osSolarisSparc { >>>>>> }; >>>>>> >>>>>> typedef osSolarisSparc osCpu; >>>>>> >>>>>> file: os.hpp >>>>>> class os { >>>>>> typedef osCpu cpu; >>>>>> typedef osCurrent pd; >>>>>> }; >>>>>> >>>>>> Webrevs: >>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> > From coleen.phillimore at oracle.com Wed Mar 13 06:48:18 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 13 Mar 2013 09:48:18 -0400 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> Message-ID: <514083A1.6060801@oracle.com> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. I only glanced at webrev 4. I don't think we can name different files the same thing for some historical reason that I can't remember. Does this design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the original which is more descriptive. This is good though, it moves along the logjam that was preventing us from sharing more code. I'll look at this more later. Coleen On 3/13/2013 9:38 AM, Rickard B?ckman wrote: > That is done in the step4 part of my webrev. :) > > /R > > On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: > >> Your reply below made think maybe we should rename posix directories and files xnix. >> Coleen >> >> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>> David, >>> >>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>> >>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>> David, >>>>> >>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>> >>>>>> Hi Rickard, >>>>>> >>>>>> An initial comment on your description here: >>>>>> >>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>> >>>>>>> doSomething() { >>>>>>> os::pd::setup(); >>>>>>> do_something(); >>>>>>> os::pd::close(); >>>>>>> } >>>>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>>>> So maybe the example here was a bit bad. Maybe this makes more sense: >>>>> >>>>> osXnix::suspend_thread(thread) { >>>>> ... >>>>> os::pd::signal_notify(thread); >>>>> ? >>>>> } >>>>> >>>>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >>>> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. >>> Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). >>> >>> That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. >>> >>> os:: is still the main interface to os things. In my example above we would have had an >>> os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. >>> os::suspend_thread() would look like: >>> { >>> os::pd::suspend_thread(); >>> } >>> >>> instead of having 4 different implementations of suspend_thread, we would now have 2. >>> >>> Hope that makes things clearer. >>> >>> Thanks >>> /R >>> >>>> David >>>> >>>>> Another example taken from os::Bsd >>>>> >>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>> >>>>> //Save caller's signal mask before setting VM signal mask >>>>> sigset_t caller_sigmask; >>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>> >>>>> OSThread* osthread = thread->osthread(); >>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>> >>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>> >>>>> if (!ReduceSignalUsage) { >>>>> if (thread->is_VM_thread()) { >>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>> } else { >>>>> // ... all other threads block BREAK_SIGNAL >>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>> } >>>>> } >>>>> } >>>>> >>>>> could be replaced by an: >>>>> >>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>> sigset_t caller_sigmask; >>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>> ? >>>>> os::pd::thread_sigmask(?); >>>>> ? >>>>> } >>>>> >>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>>>> >>>>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>> I just think that this change is large enough as it is. Further improvements are always possible. >>>>> >>>>> Thanks >>>>> /R >>>>> >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>>>> >>>>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>>>> >>>>>>> Step 1) >>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>> >>>>>>> Step 2) >>>>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>>>> >>>>>>> Step 3) >>>>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>> * Changes #includes of os__ into #include "os_cpu" >>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>> >>>>>>> Step 4) >>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>> * Renames os_.ext to os_family.ext >>>>>>> * Includes are changed from: >>>>>>> >>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>> # include "os_linux.hpp" >>>>>>> #endif >>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>> # include "os_solaris.hpp" >>>>>>> #endif >>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>> # include "os_windows.hpp" >>>>>>> #endif >>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>> # include "os_bsd.hpp" >>>>>>> #endif >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> #include "os_family.hpp" >>>>>>> >>>>>>> >>>>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>>>> >>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>> >>>>>>> doSomething() { >>>>>>> os::pd::setup(); >>>>>>> do_something(); >>>>>>> os::pd::close(); >>>>>>> } >>>>>>> >>>>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>> >>>>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>>>> >>>>>>> To show the layout of the files: >>>>>>> >>>>>>> file: os_family.hpp >>>>>>> class osSolaris { >>>>>>> }; >>>>>>> >>>>>>> typedef osSolaris osCurrent; >>>>>>> >>>>>>> file: os_cpu.hpp >>>>>>> class osSolarisSparc { >>>>>>> }; >>>>>>> >>>>>>> typedef osSolarisSparc osCpu; >>>>>>> >>>>>>> file: os.hpp >>>>>>> class os { >>>>>>> typedef osCpu cpu; >>>>>>> typedef osCurrent pd; >>>>>>> }; >>>>>>> >>>>>>> Webrevs: >>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>>>>> From rickard.backman at oracle.com Wed Mar 13 07:04:42 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 13 Mar 2013 15:04:42 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <514083A1.6060801@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> Message-ID: <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> Coleen, On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: > > Oh, you did pick xnix! I have to confess to not reading the webrevs yet. I only glanced at webrev 4. I don't think we can name different files the same thing for some historical reason that I can't remember. Does this design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the original which is more descriptive. Yes, I picked xnix. We can name different files the same thing as long as only one is part of the compilation (which it will be since the files with the same names are in different os/ directories). No the design doesn't rely on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at least rename the include files (if we really don't want to do that at least create an intermediate file) to avoid all the #if IS_SOLARIS #include os_solaris.hpp #elseif IS_LINUX #include os_linux.hpp #? #endif Thanks /R > > This is good though, it moves along the logjam that was preventing us from sharing more code. I'll look at this more later. To be able to reduce the amount of duplicated code is one of the main things I'm trying to address with this change. Thanks /R > > Coleen > > On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >> That is done in the step4 part of my webrev. :) >> >> /R >> >> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >> >>> Your reply below made think maybe we should rename posix directories and files xnix. >>> Coleen >>> >>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>> David, >>>> >>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>> >>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>> David, >>>>>> >>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>> >>>>>>> Hi Rickard, >>>>>>> >>>>>>> An initial comment on your description here: >>>>>>> >>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>>> >>>>>>>> doSomething() { >>>>>>>> os::pd::setup(); >>>>>>>> do_something(); >>>>>>>> os::pd::close(); >>>>>>>> } >>>>>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>>>>> So maybe the example here was a bit bad. Maybe this makes more sense: >>>>>> >>>>>> osXnix::suspend_thread(thread) { >>>>>> ... >>>>>> os::pd::signal_notify(thread); >>>>>> ? >>>>>> } >>>>>> >>>>>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >>>>> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. >>>> Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). >>>> >>>> That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. >>>> >>>> os:: is still the main interface to os things. In my example above we would have had an >>>> os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. >>>> os::suspend_thread() would look like: >>>> { >>>> os::pd::suspend_thread(); >>>> } >>>> >>>> instead of having 4 different implementations of suspend_thread, we would now have 2. >>>> >>>> Hope that makes things clearer. >>>> >>>> Thanks >>>> /R >>>> >>>>> David >>>>> >>>>>> Another example taken from os::Bsd >>>>>> >>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>> >>>>>> //Save caller's signal mask before setting VM signal mask >>>>>> sigset_t caller_sigmask; >>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>> >>>>>> OSThread* osthread = thread->osthread(); >>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>> >>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>> >>>>>> if (!ReduceSignalUsage) { >>>>>> if (thread->is_VM_thread()) { >>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>> } else { >>>>>> // ... all other threads block BREAK_SIGNAL >>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> could be replaced by an: >>>>>> >>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>> sigset_t caller_sigmask; >>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>> ? >>>>>> os::pd::thread_sigmask(?); >>>>>> ? >>>>>> } >>>>>> >>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>>>>> >>>>>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>> I just think that this change is large enough as it is. Further improvements are always possible. >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>>>>> >>>>>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>>>>> >>>>>>>> Step 1) >>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>> >>>>>>>> Step 2) >>>>>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>>>>> >>>>>>>> Step 3) >>>>>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>> * Changes #includes of os__ into #include "os_cpu" >>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>> >>>>>>>> Step 4) >>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>> * Includes are changed from: >>>>>>>> >>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>> # include "os_linux.hpp" >>>>>>>> #endif >>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>> # include "os_solaris.hpp" >>>>>>>> #endif >>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>> # include "os_windows.hpp" >>>>>>>> #endif >>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>> # include "os_bsd.hpp" >>>>>>>> #endif >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> #include "os_family.hpp" >>>>>>>> >>>>>>>> >>>>>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>>>>> >>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>>> >>>>>>>> doSomething() { >>>>>>>> os::pd::setup(); >>>>>>>> do_something(); >>>>>>>> os::pd::close(); >>>>>>>> } >>>>>>>> >>>>>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>> >>>>>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>>>>> >>>>>>>> To show the layout of the files: >>>>>>>> >>>>>>>> file: os_family.hpp >>>>>>>> class osSolaris { >>>>>>>> }; >>>>>>>> >>>>>>>> typedef osSolaris osCurrent; >>>>>>>> >>>>>>>> file: os_cpu.hpp >>>>>>>> class osSolarisSparc { >>>>>>>> }; >>>>>>>> >>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>> >>>>>>>> file: os.hpp >>>>>>>> class os { >>>>>>>> typedef osCpu cpu; >>>>>>>> typedef osCurrent pd; >>>>>>>> }; >>>>>>>> >>>>>>>> Webrevs: >>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> /R >>>>>>>> > From coleen.phillimore at oracle.com Wed Mar 13 07:29:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 13 Mar 2013 10:29:29 -0400 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> Message-ID: <51408D49.4020906@oracle.com> On 3/13/2013 10:04 AM, Rickard B?ckman wrote: > Coleen, > > > On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: > >> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. I only glanced at webrev 4. I don't think we can name different files the same thing for some historical reason that I can't remember. Does this design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the original which is more descriptive. > Yes, I picked xnix. We can name different files the same thing as long as only one is part of the compilation (which it will be since the files with the same names are in different os/ directories). No the design doesn't rely on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at least rename the include files (if we really don't want to do that at least create an intermediate file) to avoid all the > > #if IS_SOLARIS > #include os_solaris.hpp > #elseif IS_LINUX > #include os_linux.hpp > #? > #endif Yes, I was thinking it would be good to have the intermediate .hpp file to avoid the conditional includes for this case instead. Coleen > > Thanks > /R > >> This is good though, it moves along the logjam that was preventing us from sharing more code. I'll look at this more later. > To be able to reduce the amount of duplicated code is one of the main things I'm trying to address with this change. > > Thanks > /R > >> Coleen >> >> On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >>> That is done in the step4 part of my webrev. :) >>> >>> /R >>> >>> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >>> >>>> Your reply below made think maybe we should rename posix directories and files xnix. >>>> Coleen >>>> >>>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>>> David, >>>>> >>>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>>> >>>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>>> David, >>>>>>> >>>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>>> >>>>>>>> Hi Rickard, >>>>>>>> >>>>>>>> An initial comment on your description here: >>>>>>>> >>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>>>> >>>>>>>>> doSomething() { >>>>>>>>> os::pd::setup(); >>>>>>>>> do_something(); >>>>>>>>> os::pd::close(); >>>>>>>>> } >>>>>>>> I don't think the "pd" makes sense because you have to know what the "pd" actually is. In old terms an os::Solaris method can call another os::Solaris method because it knows it is there. If "pd" is common somehow (say pthreads functionality) then that commonality has to be named eg os::pthreads, because there might be another commonality related to some other aspect of functionality (perhaps Dtrace), so they can't both be called "pd". >>>>>>> So maybe the example here was a bit bad. Maybe this makes more sense: >>>>>>> >>>>>>> osXnix::suspend_thread(thread) { >>>>>>> ... >>>>>>> os::pd::signal_notify(thread); >>>>>>> ? >>>>>>> } >>>>>>> >>>>>>> You still have to know that pd is an interface for one os platform-dependent API. signal_notify() in this example would be implemented by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need one. >>>>>> But that seems more awkward than what we have now. Now we have os::signal_notify() which is implemented differently for solaris/linux/bsd. That specialization is done via the compile-time include mechanism. With what you suggest the methods that call things like signal_notify now have to know that they are implemented differently on different platforms whereas currently they do not need to know that. >>>>> Ah, no. At the moment we have a bunch of things that rely on knowing details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also have a lot of code that doesn't care about the details. They use the os:: interface. This does however require that all platforms have an implementation (empty or not) of whatever is in os:: (unless it is only called from some piece of code that is platform specific. In that case I do think the code is misplaced though). >>>>> >>>>> That is still the way things should work. However things that previously relied on os::Bsd or os::Linux should instead rely on os::pd. That would make that code easier to port to new platforms as well as easier to at some point unify into code that works for multiple platforms. >>>>> >>>>> os:: is still the main interface to os things. In my example above we would have had an >>>>> os::suspend_thread() - that would have had an implementation on all platforms. The *nix platforms could use the above implementation and Windows another. >>>>> os::suspend_thread() would look like: >>>>> { >>>>> os::pd::suspend_thread(); >>>>> } >>>>> >>>>> instead of having 4 different implementations of suspend_thread, we would now have 2. >>>>> >>>>> Hope that makes things clearer. >>>>> >>>>> Thanks >>>>> /R >>>>> >>>>>> David >>>>>> >>>>>>> Another example taken from os::Bsd >>>>>>> >>>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>>> >>>>>>> //Save caller's signal mask before setting VM signal mask >>>>>>> sigset_t caller_sigmask; >>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>> >>>>>>> OSThread* osthread = thread->osthread(); >>>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>>> >>>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>>> >>>>>>> if (!ReduceSignalUsage) { >>>>>>> if (thread->is_VM_thread()) { >>>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>>> } else { >>>>>>> // ... all other threads block BREAK_SIGNAL >>>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> could be replaced by an: >>>>>>> >>>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>>> sigset_t caller_sigmask; >>>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>> ? >>>>>>> os::pd::thread_sigmask(?); >>>>>>> ? >>>>>>> } >>>>>>> >>>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and thr_setsigmask on Solaris. >>>>>>> >>>>>>> I agree that having yet another level of grouping like os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>>> I just think that this change is large enough as it is. Further improvements are always possible. >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>>>>> >>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I've spent some time on trying to do some changes to (in my opinion) clean up the os_ files. >>>>>>>>> >>>>>>>>> The change is broken up into 4 web revs to make the changes easier to spot since it involves new files, renaming of files, etc. >>>>>>>>> >>>>>>>>> Step 1) >>>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>>> * The #include os_name.hpp inside the class definition is moved to before the definition of class os. >>>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, osLinux, etc. >>>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>>> >>>>>>>>> Step 2) >>>>>>>>> * Some methods existed in all or almost all os__.hpp, they were moved to os.hpp. >>>>>>>>> >>>>>>>>> Step 3) >>>>>>>>> * Removes os__.hpp and replaces it with a os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>>> * Changes #includes of os__ into #include "os_cpu" >>>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>>> >>>>>>>>> Step 4) >>>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>>> * Includes are changed from: >>>>>>>>> >>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>> # include "os_linux.hpp" >>>>>>>>> #endif >>>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>>> # include "os_solaris.hpp" >>>>>>>>> #endif >>>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>>> # include "os_windows.hpp" >>>>>>>>> #endif >>>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>>> # include "os_bsd.hpp" >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> to: >>>>>>>>> >>>>>>>>> #include "os_family.hpp" >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll try to summarize the final result the way it would look for solaris_sparc: >>>>>>>>> >>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>> These are tried together through a couple of typedefs. osSolaris is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to cpu. >>>>>>>>> This way we can now access things that was previously accessed through os::Solaris::some_method like: os::pd::some_method. That helps if we want to write some code that would be common for a couple of platforms, using an api through pd like: >>>>>>>>> >>>>>>>>> doSomething() { >>>>>>>>> os::pd::setup(); >>>>>>>>> do_something(); >>>>>>>>> os::pd::close(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> This should enable us to move code from platform specific code (thread creation, signal handling, etc) that look very similar (Linux, Bsd, Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>>> >>>>>>>>> it enables us to have platform specific includes in what os_family.hpp (used to be os_linux.hpp) for platform specific things like semaphores. >>>>>>>>> >>>>>>>>> To show the layout of the files: >>>>>>>>> >>>>>>>>> file: os_family.hpp >>>>>>>>> class osSolaris { >>>>>>>>> }; >>>>>>>>> >>>>>>>>> typedef osSolaris osCurrent; >>>>>>>>> >>>>>>>>> file: os_cpu.hpp >>>>>>>>> class osSolarisSparc { >>>>>>>>> }; >>>>>>>>> >>>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>>> >>>>>>>>> file: os.hpp >>>>>>>>> class os { >>>>>>>>> typedef osCpu cpu; >>>>>>>>> typedef osCurrent pd; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> Webrevs: >>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /R >>>>>>>>> From zhengyu.gu at oracle.com Wed Mar 13 07:52:12 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 13 Mar 2013 10:52:12 -0400 Subject: Review request: 8009813 NMT should wait all collected data to be processed before generates report when PrintNMTStatistics option is specified Message-ID: <5140929C.4080806@oracle.com> This is a simple change that has NMT to wait for collected data to be processed, before it prints out tracking data at JVM exit when PrintNMTStatisitcs option is specified. Without the wait, the data can be empty for short-lived application, or might not match the data collected through other methods. JBS: https://jbs.oracle.com/bugs/browse/JDK-8009813 Webrev: http://cr.openjdk.java.net/~zgu/8009813/webrev.00/ Test: - JPRT - vm.quick.testlist on Linux 32 Thanks, -Zhengyu From david.holmes at oracle.com Wed Mar 13 15:52:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 08:52:47 +1000 Subject: Review request: 8009813 NMT should wait all collected data to be processed before generates report when PrintNMTStatistics option is specified In-Reply-To: <5140929C.4080806@oracle.com> References: <5140929C.4080806@oracle.com> Message-ID: <5141033F.3090407@oracle.com> On 14/03/2013 12:52 AM, Zhengyu Gu wrote: > This is a simple change that has NMT to wait for collected data to be > processed, before it prints out tracking data at JVM exit when > PrintNMTStatisitcs option is specified. I'm a little concerned as to whether it is always safe to perform the actions that the wait performs, during this late phase of VM shutdown. Is there any possibility that the thread we will wait for can not in fact signal us? What is that thread and what might it be dooing? Thanks, David > Without the wait, the data can be empty for short-lived application, or > might not match the data collected through other methods. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8009813 > Webrev: http://cr.openjdk.java.net/~zgu/8009813/webrev.00/ > > Test: > - JPRT > - vm.quick.testlist on Linux 32 > > > Thanks, > > -Zhengyu From christian.thalinger at oracle.com Wed Mar 13 16:44:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Mar 2013 16:44:29 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > > On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > >> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>> >>>>> This would be the first of three fixes: >>>>> >>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>> >>>> This logic is not suitable: >>>> >>>> 541 # Testing the built JVM >>>> 542 ifeq ($(JAVA_HOME),) >>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 544 else >>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 546 endif >>>> >>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>> >>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >> >> This is so confusing. Our makefiles are an abomination! > > I couldn't agree more. > >> >> So this all started because the makefile has: >> >> JAVA_HOME=$(ABS_BOOTDIR) >> >> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >> >> So how did the boot JDK come back into this??? >> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> JAVA_HOME must point to a 64-bit OpenJDK. >>> >>> And here comes this little snippet into play: >>> >>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >> >> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: ifdef ALT_BOOTDIR COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac else ifdef BOOTDIR COMPILE.JAVAC = $(BOOTDIR)/bin/javac else ifdef JAVA_HOME else endif endif endif BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). This all sucks and needs to be replaced by something completely different. Soon. -- Chris >> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? > > I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. > > -- Chris > >> >> Thanks, >> David >> >>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>> >>>> >>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>> >>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>> >>>> >>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>> >>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>> >>> -- Chris >>> >>>> >>>> And this addition still makes no sense to me: >>>> >>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>> >>>> David >>>> >>>> >>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>> >>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>> >>>>> -- Chris >>>>> >>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From volker.simonis at gmail.com Thu Mar 14 03:35:37 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Mar 2013 11:35:37 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: <51408D49.4020906@oracle.com> References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> <51408D49.4020906@oracle.com> Message-ID: Have you tested how IDEs (Eclipse, NetBeans) behave if we have multiple files with the same name in different locations. At least navigation between such files may become unintuitive. In Emacs for example it's hard to keep them apart because they get these additional numbers in their name ('') which is only based on the order in which they were loaded. So I'd personally also prefer to stay with the old name scheme and use intermediate .hpp files. But that's just my personal opinion:) Volker On Wed, Mar 13, 2013 at 3:29 PM, Coleen Phillmore wrote: > > On 3/13/2013 10:04 AM, Rickard B?ckman wrote: >> >> Coleen, >> >> >> On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: >> >>> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. >>> I only glanced at webrev 4. I don't think we can name different files the >>> same thing for some historical reason that I can't remember. Does this >>> design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the >>> original which is more descriptive. >> >> Yes, I picked xnix. We can name different files the same thing as long as >> only one is part of the compilation (which it will be since the files with >> the same names are in different os/ directories). No the design doesn't rely >> on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at >> least rename the include files (if we really don't want to do that at least >> create an intermediate file) to avoid all the >> >> #if IS_SOLARIS >> #include os_solaris.hpp >> #elseif IS_LINUX >> #include os_linux.hpp >> #? >> #endif > > > Yes, I was thinking it would be good to have the intermediate .hpp file to > avoid the conditional includes for this case instead. > > Coleen > >> >> Thanks >> /R >> >>> This is good though, it moves along the logjam that was preventing us >>> from sharing more code. I'll look at this more later. >> >> To be able to reduce the amount of duplicated code is one of the main >> things I'm trying to address with this change. >> >> Thanks >> /R >> >>> Coleen >>> >>> On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >>>> >>>> That is done in the step4 part of my webrev. :) >>>> >>>> /R >>>> >>>> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >>>> >>>>> Your reply below made think maybe we should rename posix directories >>>>> and files xnix. >>>>> Coleen >>>>> >>>>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>>>> >>>>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>>>> >>>>>>>>> Hi Rickard, >>>>>>>>> >>>>>>>>> An initial comment on your description here: >>>>>>>>> >>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>> cpu. >>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>> using an api through pd like: >>>>>>>>>> >>>>>>>>>> doSomething() { >>>>>>>>>> os::pd::setup(); >>>>>>>>>> do_something(); >>>>>>>>>> os::pd::close(); >>>>>>>>>> } >>>>>>>>> >>>>>>>>> I don't think the "pd" makes sense because you have to know what >>>>>>>>> the "pd" actually is. In old terms an os::Solaris method can call another >>>>>>>>> os::Solaris method because it knows it is there. If "pd" is common somehow >>>>>>>>> (say pthreads functionality) then that commonality has to be named eg >>>>>>>>> os::pthreads, because there might be another commonality related to some >>>>>>>>> other aspect of functionality (perhaps Dtrace), so they can't both be called >>>>>>>>> "pd". >>>>>>>> >>>>>>>> So maybe the example here was a bit bad. Maybe this makes more >>>>>>>> sense: >>>>>>>> >>>>>>>> osXnix::suspend_thread(thread) { >>>>>>>> ... >>>>>>>> os::pd::signal_notify(thread); >>>>>>>> ? >>>>>>>> } >>>>>>>> >>>>>>>> You still have to know that pd is an interface for one os >>>>>>>> platform-dependent API. signal_notify() in this example would be implemented >>>>>>>> by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need >>>>>>>> one. >>>>>>> >>>>>>> But that seems more awkward than what we have now. Now we have >>>>>>> os::signal_notify() which is implemented differently for solaris/linux/bsd. >>>>>>> That specialization is done via the compile-time include mechanism. With >>>>>>> what you suggest the methods that call things like signal_notify now have to >>>>>>> know that they are implemented differently on different platforms whereas >>>>>>> currently they do not need to know that. >>>>>> >>>>>> Ah, no. At the moment we have a bunch of things that rely on knowing >>>>>> details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also >>>>>> have a lot of code that doesn't care about the details. They use the os:: >>>>>> interface. This does however require that all platforms have an >>>>>> implementation (empty or not) of whatever is in os:: (unless it is only >>>>>> called from some piece of code that is platform specific. In that case I do >>>>>> think the code is misplaced though). >>>>>> >>>>>> That is still the way things should work. However things that >>>>>> previously relied on os::Bsd or os::Linux should instead rely on os::pd. >>>>>> That would make that code easier to port to new platforms as well as easier >>>>>> to at some point unify into code that works for multiple platforms. >>>>>> >>>>>> os:: is still the main interface to os things. In my example above we >>>>>> would have had an >>>>>> os::suspend_thread() - that would have had an implementation on all >>>>>> platforms. The *nix platforms could use the above implementation and Windows >>>>>> another. >>>>>> os::suspend_thread() would look like: >>>>>> { >>>>>> os::pd::suspend_thread(); >>>>>> } >>>>>> >>>>>> instead of having 4 different implementations of suspend_thread, we >>>>>> would now have 2. >>>>>> >>>>>> Hope that makes things clearer. >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>>> David >>>>>>> >>>>>>>> Another example taken from os::Bsd >>>>>>>> >>>>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>>>> >>>>>>>> //Save caller's signal mask before setting VM signal mask >>>>>>>> sigset_t caller_sigmask; >>>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>> >>>>>>>> OSThread* osthread = thread->osthread(); >>>>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>>>> >>>>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>>>> >>>>>>>> if (!ReduceSignalUsage) { >>>>>>>> if (thread->is_VM_thread()) { >>>>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>>>> } else { >>>>>>>> // ... all other threads block BREAK_SIGNAL >>>>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> could be replaced by an: >>>>>>>> >>>>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>>>> sigset_t caller_sigmask; >>>>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>> ? >>>>>>>> os::pd::thread_sigmask(?); >>>>>>>> ? >>>>>>>> } >>>>>>>> >>>>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and >>>>>>>> thr_setsigmask on Solaris. >>>>>>>> >>>>>>>> I agree that having yet another level of grouping like >>>>>>>> os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>>>> I just think that this change is large enough as it is. Further >>>>>>>> improvements are always possible. >>>>>>>> >>>>>>>> Thanks >>>>>>>> /R >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I've spent some time on trying to do some changes to (in my >>>>>>>>>> opinion) clean up the os_ files. >>>>>>>>>> >>>>>>>>>> The change is broken up into 4 web revs to make the changes easier >>>>>>>>>> to spot since it involves new files, renaming of files, etc. >>>>>>>>>> >>>>>>>>>> Step 1) >>>>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are >>>>>>>>>> replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>>>> * The #include os_name.hpp inside the class definition is >>>>>>>>>> moved to before the definition of class os. >>>>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, >>>>>>>>>> osLinux, etc. >>>>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>>>> >>>>>>>>>> Step 2) >>>>>>>>>> * Some methods existed in all or almost all >>>>>>>>>> os__.hpp, they were moved to os.hpp. >>>>>>>>>> >>>>>>>>>> Step 3) >>>>>>>>>> * Removes os__.hpp and replaces it with a >>>>>>>>>> os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>>>> * Changes #includes of os__ into #include >>>>>>>>>> "os_cpu" >>>>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>>>> >>>>>>>>>> Step 4) >>>>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>>>> * Includes are changed from: >>>>>>>>>> >>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>> # include "os_linux.hpp" >>>>>>>>>> #endif >>>>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>>>> # include "os_solaris.hpp" >>>>>>>>>> #endif >>>>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>>>> # include "os_windows.hpp" >>>>>>>>>> #endif >>>>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>>>> # include "os_bsd.hpp" >>>>>>>>>> #endif >>>>>>>>>> >>>>>>>>>> to: >>>>>>>>>> >>>>>>>>>> #include "os_family.hpp" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll try to summarize the final result the way it would look for >>>>>>>>>> solaris_sparc: >>>>>>>>>> >>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>> cpu. >>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>> using an api through pd like: >>>>>>>>>> >>>>>>>>>> doSomething() { >>>>>>>>>> os::pd::setup(); >>>>>>>>>> do_something(); >>>>>>>>>> os::pd::close(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This should enable us to move code from platform specific code >>>>>>>>>> (thread creation, signal handling, etc) that look very similar (Linux, Bsd, >>>>>>>>>> Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>>>> >>>>>>>>>> it enables us to have platform specific includes in what >>>>>>>>>> os_family.hpp (used to be os_linux.hpp) for platform specific things like >>>>>>>>>> semaphores. >>>>>>>>>> >>>>>>>>>> To show the layout of the files: >>>>>>>>>> >>>>>>>>>> file: os_family.hpp >>>>>>>>>> class osSolaris { >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> typedef osSolaris osCurrent; >>>>>>>>>> >>>>>>>>>> file: os_cpu.hpp >>>>>>>>>> class osSolarisSparc { >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>>>> >>>>>>>>>> file: os.hpp >>>>>>>>>> class os { >>>>>>>>>> typedef osCpu cpu; >>>>>>>>>> typedef osCurrent pd; >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> Webrevs: >>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> > From rickard.backman at oracle.com Thu Mar 14 04:05:53 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 14 Mar 2013 12:05:53 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> <51408D49.4020906@oracle.com> Message-ID: Volker, no I haven't tried a lot of IDEs. It seems as if intermediate files are preferred. Thanks /R On Mar 14, 2013, at 11:35 AM, Volker Simonis wrote: > Have you tested how IDEs (Eclipse, NetBeans) behave if we have > multiple files with the same name in different locations. At least > navigation between such files may become unintuitive. In Emacs for > example it's hard to keep them apart because they get these additional > numbers in their name ('') which is only based on the order in > which they were loaded. > > So I'd personally also prefer to stay with the old name scheme and use > intermediate .hpp files. But that's just my personal opinion:) > > Volker > > On Wed, Mar 13, 2013 at 3:29 PM, Coleen Phillmore > wrote: >> >> On 3/13/2013 10:04 AM, Rickard B?ckman wrote: >>> >>> Coleen, >>> >>> >>> On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: >>> >>>> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. >>>> I only glanced at webrev 4. I don't think we can name different files the >>>> same thing for some historical reason that I can't remember. Does this >>>> design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the >>>> original which is more descriptive. >>> >>> Yes, I picked xnix. We can name different files the same thing as long as >>> only one is part of the compilation (which it will be since the files with >>> the same names are in different os/ directories). No the design doesn't rely >>> on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at >>> least rename the include files (if we really don't want to do that at least >>> create an intermediate file) to avoid all the >>> >>> #if IS_SOLARIS >>> #include os_solaris.hpp >>> #elseif IS_LINUX >>> #include os_linux.hpp >>> #? >>> #endif >> >> >> Yes, I was thinking it would be good to have the intermediate .hpp file to >> avoid the conditional includes for this case instead. >> >> Coleen >> >>> >>> Thanks >>> /R >>> >>>> This is good though, it moves along the logjam that was preventing us >>>> from sharing more code. I'll look at this more later. >>> >>> To be able to reduce the amount of duplicated code is one of the main >>> things I'm trying to address with this change. >>> >>> Thanks >>> /R >>> >>>> Coleen >>>> >>>> On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >>>>> >>>>> That is done in the step4 part of my webrev. :) >>>>> >>>>> /R >>>>> >>>>> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >>>>> >>>>>> Your reply below made think maybe we should rename posix directories >>>>>> and files xnix. >>>>>> Coleen >>>>>> >>>>>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>>>>> >>>>>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>>>>> >>>>>>>>> David, >>>>>>>>> >>>>>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>>>>> >>>>>>>>>> Hi Rickard, >>>>>>>>>> >>>>>>>>>> An initial comment on your description here: >>>>>>>>>> >>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>> cpu. >>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>> using an api through pd like: >>>>>>>>>>> >>>>>>>>>>> doSomething() { >>>>>>>>>>> os::pd::setup(); >>>>>>>>>>> do_something(); >>>>>>>>>>> os::pd::close(); >>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> I don't think the "pd" makes sense because you have to know what >>>>>>>>>> the "pd" actually is. In old terms an os::Solaris method can call another >>>>>>>>>> os::Solaris method because it knows it is there. If "pd" is common somehow >>>>>>>>>> (say pthreads functionality) then that commonality has to be named eg >>>>>>>>>> os::pthreads, because there might be another commonality related to some >>>>>>>>>> other aspect of functionality (perhaps Dtrace), so they can't both be called >>>>>>>>>> "pd". >>>>>>>>> >>>>>>>>> So maybe the example here was a bit bad. Maybe this makes more >>>>>>>>> sense: >>>>>>>>> >>>>>>>>> osXnix::suspend_thread(thread) { >>>>>>>>> ... >>>>>>>>> os::pd::signal_notify(thread); >>>>>>>>> ? >>>>>>>>> } >>>>>>>>> >>>>>>>>> You still have to know that pd is an interface for one os >>>>>>>>> platform-dependent API. signal_notify() in this example would be implemented >>>>>>>>> by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need >>>>>>>>> one. >>>>>>>> >>>>>>>> But that seems more awkward than what we have now. Now we have >>>>>>>> os::signal_notify() which is implemented differently for solaris/linux/bsd. >>>>>>>> That specialization is done via the compile-time include mechanism. With >>>>>>>> what you suggest the methods that call things like signal_notify now have to >>>>>>>> know that they are implemented differently on different platforms whereas >>>>>>>> currently they do not need to know that. >>>>>>> >>>>>>> Ah, no. At the moment we have a bunch of things that rely on knowing >>>>>>> details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also >>>>>>> have a lot of code that doesn't care about the details. They use the os:: >>>>>>> interface. This does however require that all platforms have an >>>>>>> implementation (empty or not) of whatever is in os:: (unless it is only >>>>>>> called from some piece of code that is platform specific. In that case I do >>>>>>> think the code is misplaced though). >>>>>>> >>>>>>> That is still the way things should work. However things that >>>>>>> previously relied on os::Bsd or os::Linux should instead rely on os::pd. >>>>>>> That would make that code easier to port to new platforms as well as easier >>>>>>> to at some point unify into code that works for multiple platforms. >>>>>>> >>>>>>> os:: is still the main interface to os things. In my example above we >>>>>>> would have had an >>>>>>> os::suspend_thread() - that would have had an implementation on all >>>>>>> platforms. The *nix platforms could use the above implementation and Windows >>>>>>> another. >>>>>>> os::suspend_thread() would look like: >>>>>>> { >>>>>>> os::pd::suspend_thread(); >>>>>>> } >>>>>>> >>>>>>> instead of having 4 different implementations of suspend_thread, we >>>>>>> would now have 2. >>>>>>> >>>>>>> Hope that makes things clearer. >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Another example taken from os::Bsd >>>>>>>>> >>>>>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>>>>> >>>>>>>>> //Save caller's signal mask before setting VM signal mask >>>>>>>>> sigset_t caller_sigmask; >>>>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>> >>>>>>>>> OSThread* osthread = thread->osthread(); >>>>>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>>>>> >>>>>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>>>>> >>>>>>>>> if (!ReduceSignalUsage) { >>>>>>>>> if (thread->is_VM_thread()) { >>>>>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>>>>> } else { >>>>>>>>> // ... all other threads block BREAK_SIGNAL >>>>>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> could be replaced by an: >>>>>>>>> >>>>>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>>>>> sigset_t caller_sigmask; >>>>>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>> ? >>>>>>>>> os::pd::thread_sigmask(?); >>>>>>>>> ? >>>>>>>>> } >>>>>>>>> >>>>>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and >>>>>>>>> thr_setsigmask on Solaris. >>>>>>>>> >>>>>>>>> I agree that having yet another level of grouping like >>>>>>>>> os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>>>>> I just think that this change is large enough as it is. Further >>>>>>>>> improvements are always possible. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /R >>>>>>>>> >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I've spent some time on trying to do some changes to (in my >>>>>>>>>>> opinion) clean up the os_ files. >>>>>>>>>>> >>>>>>>>>>> The change is broken up into 4 web revs to make the changes easier >>>>>>>>>>> to spot since it involves new files, renaming of files, etc. >>>>>>>>>>> >>>>>>>>>>> Step 1) >>>>>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are >>>>>>>>>>> replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>>>>> * The #include os_name.hpp inside the class definition is >>>>>>>>>>> moved to before the definition of class os. >>>>>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, >>>>>>>>>>> osLinux, etc. >>>>>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>>>>> >>>>>>>>>>> Step 2) >>>>>>>>>>> * Some methods existed in all or almost all >>>>>>>>>>> os__.hpp, they were moved to os.hpp. >>>>>>>>>>> >>>>>>>>>>> Step 3) >>>>>>>>>>> * Removes os__.hpp and replaces it with a >>>>>>>>>>> os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>>>>> * Changes #includes of os__ into #include >>>>>>>>>>> "os_cpu" >>>>>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>>>>> >>>>>>>>>>> Step 4) >>>>>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>>>>> * Includes are changed from: >>>>>>>>>>> >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>> # include "os_linux.hpp" >>>>>>>>>>> #endif >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>>>>> # include "os_solaris.hpp" >>>>>>>>>>> #endif >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>>>>> # include "os_windows.hpp" >>>>>>>>>>> #endif >>>>>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>>>>> # include "os_bsd.hpp" >>>>>>>>>>> #endif >>>>>>>>>>> >>>>>>>>>>> to: >>>>>>>>>>> >>>>>>>>>>> #include "os_family.hpp" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll try to summarize the final result the way it would look for >>>>>>>>>>> solaris_sparc: >>>>>>>>>>> >>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>> cpu. >>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>> using an api through pd like: >>>>>>>>>>> >>>>>>>>>>> doSomething() { >>>>>>>>>>> os::pd::setup(); >>>>>>>>>>> do_something(); >>>>>>>>>>> os::pd::close(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This should enable us to move code from platform specific code >>>>>>>>>>> (thread creation, signal handling, etc) that look very similar (Linux, Bsd, >>>>>>>>>>> Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>>>>> >>>>>>>>>>> it enables us to have platform specific includes in what >>>>>>>>>>> os_family.hpp (used to be os_linux.hpp) for platform specific things like >>>>>>>>>>> semaphores. >>>>>>>>>>> >>>>>>>>>>> To show the layout of the files: >>>>>>>>>>> >>>>>>>>>>> file: os_family.hpp >>>>>>>>>>> class osSolaris { >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> typedef osSolaris osCurrent; >>>>>>>>>>> >>>>>>>>>>> file: os_cpu.hpp >>>>>>>>>>> class osSolarisSparc { >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>>>>> >>>>>>>>>>> file: os.hpp >>>>>>>>>>> class os { >>>>>>>>>>> typedef osCpu cpu; >>>>>>>>>>> typedef osCurrent pd; >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> Webrevs: >>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> /R >>>>>>>>>>> >> From zhengyu.gu at oracle.com Thu Mar 14 06:28:10 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 14 Mar 2013 09:28:10 -0400 Subject: Review request: 8009813 NMT should wait all collected data to be processed before generates report when PrintNMTStatistics option is specified In-Reply-To: <5141033F.3090407@oracle.com> References: <5140929C.4080806@oracle.com> <5141033F.3090407@oracle.com> Message-ID: <5141D06A.4080705@oracle.com> Hi David, On 3/13/2013 6:52 PM, David Holmes wrote: > On 14/03/2013 12:52 AM, Zhengyu Gu wrote: >> This is a simple change that has NMT to wait for collected data to be >> processed, before it prints out tracking data at JVM exit when >> PrintNMTStatisitcs option is specified. > > I'm a little concerned as to whether it is always safe to perform the > actions that the wait performs, during this late phase of VM shutdown. > Is there any possibility that the thread we will wait for can not in > fact signal us? What is that thread and what might it be dooing? > The wait is on NMT worker thread. It waits NMT worker to make enough progress, so NMT can report memory usage that is fairly close to the state at JVM exit. The NMT worker is shutdown after processing the report, if NMT is shutdown by other factors, the wait should abort. BTW, PrintNMTStatistics is a JVM diagnostic. By default, it is off. Thanks, -Zhengyu > Thanks, > David > >> Without the wait, the data can be empty for short-lived application, or >> might not match the data collected through other methods. >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8009813 >> Webrev: http://cr.openjdk.java.net/~zgu/8009813/webrev.00/ >> >> Test: >> - JPRT >> - vm.quick.testlist on Linux 32 >> >> >> Thanks, >> >> -Zhengyu From nils.eliasson at oracle.com Thu Mar 14 07:23:13 2013 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Thu, 14 Mar 2013 14:23:13 +0000 Subject: hg: hsx/hsx24/hotspot: 8003934: Fix generation of malformed options to Projectcreator Message-ID: <20130314142318.299B84813A@hg.openjdk.java.net> Changeset: 8a853c83f551 Author: neliasso Date: 2012-12-06 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8a853c83f551 8003934: Fix generation of malformed options to Projectcreator Summary: Makefile produces unmatched quotes due to nmake bug Reviewed-by: jwilhelm, brutisso ! make/windows/projectfiles/common/Makefile From daniel.daugherty at oracle.com Thu Mar 14 09:41:43 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 14 Mar 2013 16:41:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130314164208.0C5BB4814C@hg.openjdk.java.net> Changeset: 255c0a4cb4eb Author: sla Date: 2013-03-05 08:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/255c0a4cb4eb 8009287: [parfait] Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Reviewed-by: dholmes, kvn, mikael, morris ! agent/src/os/linux/ps_core.c Changeset: 9058789475af Author: iklam Date: 2013-03-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9058789475af 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu Contributed-by: ioi.lam at oracle.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c Changeset: 6b803ba47588 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b803ba47588 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 3efdfd6ddbf2 Author: coleenp Date: 2013-03-08 11:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3efdfd6ddbf2 8003553: NPG: metaspace objects should be zeroed in constructors Summary: Zero metadata in constructors, not in allocation (and some in constructors) Reviewed-by: jmasa, sspitsyn ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 252ad8d5f22b Author: dcubed Date: 2013-03-08 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/252ad8d5f22b Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 35ef86296a5d Author: dcubed Date: 2013-03-08 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35ef86296a5d Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 5939f5953b45 Author: coleenp Date: 2013-03-13 09:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5939f5953b45 8009836: nsk/regression/b4222717 fails with empty stack trace Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcom crashes, add back zeroing to metablock Reviewed-by: dholmes, rbackman ! src/share/vm/memory/metablock.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/method.cpp Changeset: 96480359523a Author: coleenp Date: 2013-03-11 14:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96480359523a 8008965: @Contended fails with classes having static fields Summary: Disable @Contended support for static fields Reviewed-by: coleenp, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp + test/runtime/8003985/Test8003985.java Changeset: d6320e955c89 Author: coleenp Date: 2013-03-13 13:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d6320e955c89 Merge Changeset: 0ede345ec7c9 Author: coleenp Date: 2013-03-13 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0ede345ec7c9 8009829: CDS: JDK JPRT test fails crash in Symbol::equals() Summary: -Xshare:dump was creating a Symbol in C_heap. There's an assert there that jdk jprt wasn't hitting because it was only done in product Reviewed-by: dholmes, hseigel, iklam ! src/share/vm/classfile/symbolTable.cpp Changeset: c8b31b461e1a Author: coleenp Date: 2013-03-13 17:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c8b31b461e1a 8003419: NPG: Clean up metadata created during class loading if failure Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. Reviewed-by: jmasa, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp From vladimir.danushevsky at oracle.com Thu Mar 14 11:40:13 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 14 Mar 2013 18:40:13 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130314184030.3FF6848153@hg.openjdk.java.net> Changeset: fad90b102190 Author: jprovino Date: 2013-03-06 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fad90b102190 8008310: Some adjustments needed to minimal VM warnings and errors for unsupported command line options Summary: Changes to arguments.cpp for warnings vs. errors. Changes for CDS arguments. Reviewed-by: coleenp, cjplummer ! make/excludeSrc.make ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 47bc9800972c Author: jprovino Date: 2013-03-06 13:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/47bc9800972c 8006498: #if is wrong in the code. Summary: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not. Reviewed-by: dholmes, mikael ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiTrace.hpp Changeset: 67342b960b47 Author: jprovino Date: 2013-03-06 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/67342b960b47 8008474: Add -Wundef to warning flags. Summary: Force use of undefined macros to be and error. Reviewed-by: dholmes, mikael ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: cb75b67f04fb Author: jprovino Date: 2013-03-08 12:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cb75b67f04fb Merge ! make/bsd/makefiles/gcc.make Changeset: 69ffa4ac9e53 Author: jprovino Date: 2013-03-12 00:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69ffa4ac9e53 8009835: Only produce a warning when -Xshare:auto is explicitly requested Summary: The minimal JVM is printing a warning message for default settings when it should quitely ignore them. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 9102c4111564 Author: jprovino Date: 2013-03-14 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9102c4111564 Merge Changeset: ed53b50794d7 Author: vladidan Date: 2013-03-14 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed53b50794d7 Merge From krystal.mo at oracle.com Thu Mar 14 12:44:15 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 14 Mar 2013 12:44:15 -0700 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Message-ID: <5142288F.1050709@oracle.com> Hi all, Could I get a review for this small fix, please? Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 Description: Currently Abstract_VM_Version::internal_vm_info_string() recognizes MSVC versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being built with VS2010, it should recognize that compiler (along with new VS2012), so that when its value appears in crash logs, it shouldn't say: "unknown MS VC++:1600", which is what can be seen in JDK7u's crash log. Thanks, Kris From zhengyu.gu at oracle.com Thu Mar 14 12:50:58 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 14 Mar 2013 15:50:58 -0400 Subject: Review Request: 8009614 nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Message-ID: <51422A22.8070408@oracle.com> A simple fix to align up virtual memory allocation size to os defined granularity. Bug: https://jbs.oracle.com/bugs/browse/JDK-8009614 Webrev: http://cr.openjdk.java.net/~zgu/8009614/webrev.00/ Test: - Test case: nsk.split_verifier.stress.ifelse002_30.ifelse002 - JPRT Thanks, -Zhengyu From zhengyu.gu at oracle.com Thu Mar 14 13:10:25 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 14 Mar 2013 16:10:25 -0400 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <5142288F.1050709@oracle.com> References: <5142288F.1050709@oracle.com> Message-ID: <51422EB1.3070804@oracle.com> Looks good to me. -Zhengyu On 3/14/2013 3:44 PM, Krystal Mo wrote: > Hi all, > > Could I get a review for this small fix, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ > CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 > > Description: > > Currently Abstract_VM_Version::internal_vm_info_string() recognizes > MSVC versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being > built with VS2010, it should recognize that compiler (along with new > VS2012), so that when its value appears in crash logs, it shouldn't > say: "unknown MS VC++:1600", which is what can be seen in JDK7u's > crash log. > > Thanks, > Kris From vladimir.kozlov at oracle.com Thu Mar 14 13:31:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Mar 2013 13:31:42 -0700 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <5142288F.1050709@oracle.com> References: <5142288F.1050709@oracle.com> Message-ID: <514233AE.4020009@oracle.com> Good. Vladimir On 3/14/13 12:44 PM, Krystal Mo wrote: > Hi all, > > Could I get a review for this small fix, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ > CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 > > Description: > > Currently Abstract_VM_Version::internal_vm_info_string() recognizes MSVC > versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being built > with VS2010, it should recognize that compiler (along with new VS2012), > so that when its value appears in crash logs, it shouldn't say: "unknown > MS VC++:1600", which is what can be seen in JDK7u's crash log. > > Thanks, > Kris From krystal.mo at oracle.com Thu Mar 14 13:35:19 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 14 Mar 2013 13:35:19 -0700 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <51422EB1.3070804@oracle.com> References: <5142288F.1050709@oracle.com> <51422EB1.3070804@oracle.com> Message-ID: <51423487.7080204@oracle.com> Thank you, Zhengyu! - Kris On 2013/3/14 13:10, Zhengyu Gu wrote: > Looks good to me. > > -Zhengyu > > On 3/14/2013 3:44 PM, Krystal Mo wrote: >> Hi all, >> >> Could I get a review for this small fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ >> CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 >> >> Description: >> >> Currently Abstract_VM_Version::internal_vm_info_string() recognizes >> MSVC versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is >> being built with VS2010, it should recognize that compiler (along >> with new VS2012), so that when its value appears in crash logs, it >> shouldn't say: "unknown MS VC++:1600", which is what can be seen in >> JDK7u's crash log. >> >> Thanks, >> Kris > From krystal.mo at oracle.com Thu Mar 14 13:35:38 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 14 Mar 2013 13:35:38 -0700 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <514233AE.4020009@oracle.com> References: <5142288F.1050709@oracle.com> <514233AE.4020009@oracle.com> Message-ID: <5142349A.7020804@oracle.com> Thank you, Vladimir! - Kris On 2013/3/14 13:31, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 3/14/13 12:44 PM, Krystal Mo wrote: >> Hi all, >> >> Could I get a review for this small fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ >> CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 >> >> Description: >> >> Currently Abstract_VM_Version::internal_vm_info_string() recognizes MSVC >> versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being built >> with VS2010, it should recognize that compiler (along with new VS2012), >> so that when its value appears in crash logs, it shouldn't say: "unknown >> MS VC++:1600", which is what can be seen in JDK7u's crash log. >> >> Thanks, >> Kris From alejandro.murillo at oracle.com Thu Mar 14 14:48:37 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 14 Mar 2013 21:48:37 +0000 Subject: hg: hsx/hsx24/hotspot: 21 new changesets Message-ID: <20130314214922.D69F84815F@hg.openjdk.java.net> Changeset: be57a8d7a1a7 Author: katleman Date: 2013-01-29 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be57a8d7a1a7 Added tag jdk7u13-b10 for changeset e0e52e35e0c5 ! .hgtags Changeset: 1b40559b91cb Author: katleman Date: 2013-02-01 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1b40559b91cb Added tag jdk7u13-b30 for changeset be57a8d7a1a7 ! .hgtags Changeset: 5fbe0cae3a2a Author: ewendeli Date: 2013-02-01 23:28 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5fbe0cae3a2a Merge ! .hgtags Changeset: 30d72c9abb56 Author: katleman Date: 2013-02-07 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/30d72c9abb56 Added tag jdk7u15-b01 for changeset 5fbe0cae3a2a ! .hgtags Changeset: 221c64550c5b Author: katleman Date: 2013-02-08 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/221c64550c5b Added tag jdk7u15-b02 for changeset 30d72c9abb56 ! .hgtags Changeset: 5b3a2f8eb010 Author: ewendeli Date: 2013-02-13 19:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5b3a2f8eb010 Merge ! .hgtags Changeset: aed229ba0679 Author: ewendeli Date: 2013-02-20 19:49 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aed229ba0679 Merge ! .hgtags Changeset: 5b55cef461b0 Author: katleman Date: 2013-02-13 18:19 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5b55cef461b0 Added tag jdk7u15-b30 for changeset 221c64550c5b ! .hgtags Changeset: 53ab22d4f44c Author: katleman Date: 2013-02-18 12:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/53ab22d4f44c Added tag jdk7u15-b03 for changeset 5b55cef461b0 ! .hgtags Changeset: d2b587401182 Author: katleman Date: 2013-02-18 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d2b587401182 Added tag jdk7u15-b32 for changeset 34a7b6dda06e ! .hgtags Changeset: a4dfda7a2655 Author: katleman Date: 2013-02-18 12:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a4dfda7a2655 Merge ! .hgtags Changeset: 0d82bf449a61 Author: katleman Date: 2013-02-26 12:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0d82bf449a61 Added tag jdk7u17-b01 for changeset a4dfda7a2655 ! .hgtags Changeset: 7b357c079370 Author: katleman Date: 2013-03-01 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7b357c079370 Added tag jdk7u17-b02 for changeset 0d82bf449a61 ! .hgtags Changeset: 195931672178 Author: coffeys Date: 2013-03-02 17:24 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/195931672178 Merge ! .hgtags Changeset: e8e195210ada Author: amurillo Date: 2013-03-05 14:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e8e195210ada Merge ! .hgtags Changeset: b1030375770f Author: amurillo Date: 2013-03-05 14:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b1030375770f Merge ! .hgtags Changeset: 0addb9ef7b4e Author: lana Date: 2013-03-11 14:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0addb9ef7b4e Merge ! .hgtags Changeset: 10e0043bda08 Author: amurillo Date: 2013-03-12 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/10e0043bda08 Merge ! .hgtags Changeset: 55d0822d1370 Author: katleman Date: 2013-03-13 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/55d0822d1370 Added tag jdk7u14-b16 for changeset 10e0043bda08 ! .hgtags Changeset: 7416b0a84e3c Author: amurillo Date: 2013-03-14 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7416b0a84e3c Merge Changeset: 61822da2b149 Author: amurillo Date: 2013-03-14 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/61822da2b149 Added tag hs24-b36 for changeset 7416b0a84e3c ! .hgtags From alejandro.murillo at oracle.com Thu Mar 14 19:12:44 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Mar 2013 02:12:44 +0000 Subject: hg: hsx/hsx24/hotspot: 8010103: new hotspot build - hs24-b37 Message-ID: <20130315021249.24CD54816F@hg.openjdk.java.net> Changeset: f3338eb19a6a Author: amurillo Date: 2013-03-14 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f3338eb19a6a 8010103: new hotspot build - hs24-b37 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Thu Mar 14 19:57:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 12:57:12 +1000 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <5142288F.1050709@oracle.com> References: <5142288F.1050709@oracle.com> Message-ID: <51428E08.7030400@oracle.com> All good. Pity the compilers don't expose a macro for their name so that we don't have to track this :( David On 15/03/2013 5:44 AM, Krystal Mo wrote: > Hi all, > > Could I get a review for this small fix, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ > CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 > > Description: > > Currently Abstract_VM_Version::internal_vm_info_string() recognizes MSVC > versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being built > with VS2010, it should recognize that compiler (along with new VS2012), > so that when its value appears in crash logs, it shouldn't say: "unknown > MS VC++:1600", which is what can be seen in JDK7u's crash log. > > Thanks, > Kris From david.holmes at oracle.com Thu Mar 14 19:58:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 12:58:31 +1000 Subject: Review Request: 8009614 nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() In-Reply-To: <51422A22.8070408@oracle.com> References: <51422A22.8070408@oracle.com> Message-ID: <51428E57.9080509@oracle.com> On 15/03/2013 5:50 AM, Zhengyu Gu wrote: > A simple fix to align up virtual memory allocation size to os defined > granularity. > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8009614 > Webrev: http://cr.openjdk.java.net/~zgu/8009614/webrev.00/ Seems reasonable. David ----- > Test: > - Test case: nsk.split_verifier.stress.ifelse002_30.ifelse002 > - JPRT > > > Thanks, > > -Zhengyu From christian.thalinger at oracle.com Thu Mar 14 20:31:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Mar 2013 20:31:55 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK Message-ID: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> [This is the HotSpot part of JEP 176] http://cr.openjdk.java.net/~twisti/7198429 7198429: need checked categorization of caller-sensitive methods in the JDK Reviewed-by: More information in JEP 176: http://openjdk.java.net/jeps/176 src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/javaClasses.hpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/classfile/vmSymbols.hpp src/share/vm/oops/method.cpp src/share/vm/oops/method.hpp src/share/vm/opto/library_call.cpp src/share/vm/prims/jvm.cpp src/share/vm/prims/methodHandles.cpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/vframe.cpp src/share/vm/runtime/vframe.hpp From david.holmes at oracle.com Thu Mar 14 23:21:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 16:21:19 +1000 Subject: RFR: 8008783 JPRT target updates Message-ID: <5142BDDF.9040907@oracle.com> The CR for this is not public. These are just some renamings of our JPRT build targets. http://cr.openjdk.java.net/~dholmes/8008783/webrev/ This will be pushed via hotspot-emb once some internal changes are in place to deal with the new names. I will need a hotspot Reviewer for this please. (You know who you are! ;-)) Thanks, David From krystal.mo at oracle.com Fri Mar 15 01:54:53 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 15 Mar 2013 01:54:53 -0700 Subject: Request for review (XS): 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 In-Reply-To: <51428E08.7030400@oracle.com> References: <5142288F.1050709@oracle.com> <51428E08.7030400@oracle.com> Message-ID: <5142E1DD.7000700@oracle.com> Thank you, David! I'm sorry I made the push early so I didn't list you or Vladimir as Reviewer in this CR. Thanks, Kris On 2013/3/14 19:57, David Holmes wrote: > All good. > > Pity the compilers don't expose a macro for their name so that we > don't have to track this :( > > David > > On 15/03/2013 5:44 AM, Krystal Mo wrote: >> Hi all, >> >> Could I get a review for this small fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8010116/webrev.00/ >> CR: http://bugs.sun.com/view_bug.do?bug_id=8010116 >> >> Description: >> >> Currently Abstract_VM_Version::internal_vm_info_string() recognizes MSVC >> versions from 5.0 to 9.0 (VS2008). Since JDK7 can be and is being built >> with VS2010, it should recognize that compiler (along with new VS2012), >> so that when its value appears in crash logs, it shouldn't say: "unknown >> MS VC++:1600", which is what can be seen in JDK7u's crash log. >> >> Thanks, >> Kris From morris.meyer at oracle.com Fri Mar 15 04:23:51 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Fri, 15 Mar 2013 11:23:51 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130315112408.2D6F24817A@hg.openjdk.java.net> Changeset: 0094485b46c7 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0094485b46c7 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: 056ab43544a4 Author: neliasso Date: 2013-03-13 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/056ab43544a4 8009721: Make PhaseLive independent from regalloc Summary: Moved class definition of LRG_List from chaitin.hpp to live.hpp Reviewed-by: kvn, rbackman, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/live.hpp Changeset: 6d98efabf3ba Author: neliasso Date: 2013-03-13 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d98efabf3ba Merge Changeset: b7c2c5b2572c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b7c2c5b2572c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp Changeset: 71f13276159d Author: morris Date: 2013-03-14 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71f13276159d 8008560: [parfait] Null pointer deference in hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Summary: add null pointer check in signal handler Reviewed-by: kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: fba788946616 Author: morris Date: 2013-03-14 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fba788946616 Merge From zhengyu.gu at oracle.com Fri Mar 15 05:59:52 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 15 Mar 2013 08:59:52 -0400 Subject: Review Request: 8009614 nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() In-Reply-To: <51428E57.9080509@oracle.com> References: <51422A22.8070408@oracle.com> <51428E57.9080509@oracle.com> Message-ID: <51431B48.8010803@oracle.com> Thanks! -Zhengyu On 3/14/2013 10:58 PM, David Holmes wrote: > On 15/03/2013 5:50 AM, Zhengyu Gu wrote: >> A simple fix to align up virtual memory allocation size to os defined >> granularity. >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8009614 >> Webrev: http://cr.openjdk.java.net/~zgu/8009614/webrev.00/ > > Seems reasonable. > > David > ----- > >> Test: >> - Test case: nsk.split_verifier.stress.ifelse002_30.ifelse002 >> - JPRT >> >> >> Thanks, >> >> -Zhengyu From thomas.stuefe at gmail.com Fri Mar 15 06:20:40 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Fri, 15 Mar 2013 14:20:40 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> <51408D49.4020906@oracle.com> Message-ID: Hi Richard, I think the classes can do with some refactoring, especially putting common implementations up to common files. However, I am also unhappy with the renaming. We spend a lot of time in those files, on a daily basis, and our developers use everything from Eclipse and Visual Studio to raw emacs and vi (like, me). Many editors just show the file name without path at a prominent place. We often have to change things for multiple platforms, compare different platform implementations and so on, so it is common to have different os_... files open at the same time. If they are all named the same, this will get confusing and likely cause errors. Also, please remember that we (SAP) support more platforms that you (Aix, HP-UX etc) as well as more CPUs. So we would have even more possibilities for errors. Please, lets keep the old naming scheme! Thanks, Thomas St?fe, SAP Germany On Thu, Mar 14, 2013 at 12:05 PM, Rickard B?ckman wrote: > Volker, > > no I haven't tried a lot of IDEs. It seems as if intermediate files are preferred. > > Thanks > /R > > On Mar 14, 2013, at 11:35 AM, Volker Simonis wrote: > >> Have you tested how IDEs (Eclipse, NetBeans) behave if we have >> multiple files with the same name in different locations. At least >> navigation between such files may become unintuitive. In Emacs for >> example it's hard to keep them apart because they get these additional >> numbers in their name ('') which is only based on the order in >> which they were loaded. >> >> So I'd personally also prefer to stay with the old name scheme and use >> intermediate .hpp files. But that's just my personal opinion:) >> >> Volker >> >> On Wed, Mar 13, 2013 at 3:29 PM, Coleen Phillmore >> wrote: >>> >>> On 3/13/2013 10:04 AM, Rickard B?ckman wrote: >>>> >>>> Coleen, >>>> >>>> >>>> On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: >>>> >>>>> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. >>>>> I only glanced at webrev 4. I don't think we can name different files the >>>>> same thing for some historical reason that I can't remember. Does this >>>>> design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the >>>>> original which is more descriptive. >>>> >>>> Yes, I picked xnix. We can name different files the same thing as long as >>>> only one is part of the compilation (which it will be since the files with >>>> the same names are in different os/ directories). No the design doesn't rely >>>> on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at >>>> least rename the include files (if we really don't want to do that at least >>>> create an intermediate file) to avoid all the >>>> >>>> #if IS_SOLARIS >>>> #include os_solaris.hpp >>>> #elseif IS_LINUX >>>> #include os_linux.hpp >>>> #? >>>> #endif >>> >>> >>> Yes, I was thinking it would be good to have the intermediate .hpp file to >>> avoid the conditional includes for this case instead. >>> >>> Coleen >>> >>>> >>>> Thanks >>>> /R >>>> >>>>> This is good though, it moves along the logjam that was preventing us >>>>> from sharing more code. I'll look at this more later. >>>> >>>> To be able to reduce the amount of duplicated code is one of the main >>>> things I'm trying to address with this change. >>>> >>>> Thanks >>>> /R >>>> >>>>> Coleen >>>>> >>>>> On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >>>>>> >>>>>> That is done in the step4 part of my webrev. :) >>>>>> >>>>>> /R >>>>>> >>>>>> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >>>>>> >>>>>>> Your reply below made think maybe we should rename posix directories >>>>>>> and files xnix. >>>>>>> Coleen >>>>>>> >>>>>>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>>>>>> >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Hi Rickard, >>>>>>>>>>> >>>>>>>>>>> An initial comment on your description here: >>>>>>>>>>> >>>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>>> cpu. >>>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>>> using an api through pd like: >>>>>>>>>>>> >>>>>>>>>>>> doSomething() { >>>>>>>>>>>> os::pd::setup(); >>>>>>>>>>>> do_something(); >>>>>>>>>>>> os::pd::close(); >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> I don't think the "pd" makes sense because you have to know what >>>>>>>>>>> the "pd" actually is. In old terms an os::Solaris method can call another >>>>>>>>>>> os::Solaris method because it knows it is there. If "pd" is common somehow >>>>>>>>>>> (say pthreads functionality) then that commonality has to be named eg >>>>>>>>>>> os::pthreads, because there might be another commonality related to some >>>>>>>>>>> other aspect of functionality (perhaps Dtrace), so they can't both be called >>>>>>>>>>> "pd". >>>>>>>>>> >>>>>>>>>> So maybe the example here was a bit bad. Maybe this makes more >>>>>>>>>> sense: >>>>>>>>>> >>>>>>>>>> osXnix::suspend_thread(thread) { >>>>>>>>>> ... >>>>>>>>>> os::pd::signal_notify(thread); >>>>>>>>>> ? >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> You still have to know that pd is an interface for one os >>>>>>>>>> platform-dependent API. signal_notify() in this example would be implemented >>>>>>>>>> by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need >>>>>>>>>> one. >>>>>>>>> >>>>>>>>> But that seems more awkward than what we have now. Now we have >>>>>>>>> os::signal_notify() which is implemented differently for solaris/linux/bsd. >>>>>>>>> That specialization is done via the compile-time include mechanism. With >>>>>>>>> what you suggest the methods that call things like signal_notify now have to >>>>>>>>> know that they are implemented differently on different platforms whereas >>>>>>>>> currently they do not need to know that. >>>>>>>> >>>>>>>> Ah, no. At the moment we have a bunch of things that rely on knowing >>>>>>>> details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also >>>>>>>> have a lot of code that doesn't care about the details. They use the os:: >>>>>>>> interface. This does however require that all platforms have an >>>>>>>> implementation (empty or not) of whatever is in os:: (unless it is only >>>>>>>> called from some piece of code that is platform specific. In that case I do >>>>>>>> think the code is misplaced though). >>>>>>>> >>>>>>>> That is still the way things should work. However things that >>>>>>>> previously relied on os::Bsd or os::Linux should instead rely on os::pd. >>>>>>>> That would make that code easier to port to new platforms as well as easier >>>>>>>> to at some point unify into code that works for multiple platforms. >>>>>>>> >>>>>>>> os:: is still the main interface to os things. In my example above we >>>>>>>> would have had an >>>>>>>> os::suspend_thread() - that would have had an implementation on all >>>>>>>> platforms. The *nix platforms could use the above implementation and Windows >>>>>>>> another. >>>>>>>> os::suspend_thread() would look like: >>>>>>>> { >>>>>>>> os::pd::suspend_thread(); >>>>>>>> } >>>>>>>> >>>>>>>> instead of having 4 different implementations of suspend_thread, we >>>>>>>> would now have 2. >>>>>>>> >>>>>>>> Hope that makes things clearer. >>>>>>>> >>>>>>>> Thanks >>>>>>>> /R >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Another example taken from os::Bsd >>>>>>>>>> >>>>>>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>>>>>> >>>>>>>>>> //Save caller's signal mask before setting VM signal mask >>>>>>>>>> sigset_t caller_sigmask; >>>>>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>>> >>>>>>>>>> OSThread* osthread = thread->osthread(); >>>>>>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>>>>>> >>>>>>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>>>>>> >>>>>>>>>> if (!ReduceSignalUsage) { >>>>>>>>>> if (thread->is_VM_thread()) { >>>>>>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>>>>>> } else { >>>>>>>>>> // ... all other threads block BREAK_SIGNAL >>>>>>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> could be replaced by an: >>>>>>>>>> >>>>>>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>>>>>> sigset_t caller_sigmask; >>>>>>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>>> ? >>>>>>>>>> os::pd::thread_sigmask(?); >>>>>>>>>> ? >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and >>>>>>>>>> thr_setsigmask on Solaris. >>>>>>>>>> >>>>>>>>>> I agree that having yet another level of grouping like >>>>>>>>>> os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>>>>>> I just think that this change is large enough as it is. Further >>>>>>>>>> improvements are always possible. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I've spent some time on trying to do some changes to (in my >>>>>>>>>>>> opinion) clean up the os_ files. >>>>>>>>>>>> >>>>>>>>>>>> The change is broken up into 4 web revs to make the changes easier >>>>>>>>>>>> to spot since it involves new files, renaming of files, etc. >>>>>>>>>>>> >>>>>>>>>>>> Step 1) >>>>>>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are >>>>>>>>>>>> replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>>>>>> * The #include os_name.hpp inside the class definition is >>>>>>>>>>>> moved to before the definition of class os. >>>>>>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, >>>>>>>>>>>> osLinux, etc. >>>>>>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>>>>>> >>>>>>>>>>>> Step 2) >>>>>>>>>>>> * Some methods existed in all or almost all >>>>>>>>>>>> os__.hpp, they were moved to os.hpp. >>>>>>>>>>>> >>>>>>>>>>>> Step 3) >>>>>>>>>>>> * Removes os__.hpp and replaces it with a >>>>>>>>>>>> os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>>>>>> * Changes #includes of os__ into #include >>>>>>>>>>>> "os_cpu" >>>>>>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>>>>>> >>>>>>>>>>>> Step 4) >>>>>>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>>>>>> * Includes are changed from: >>>>>>>>>>>> >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>> # include "os_linux.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>>>>>> # include "os_solaris.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>>>>>> # include "os_windows.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>>>>>> # include "os_bsd.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> >>>>>>>>>>>> to: >>>>>>>>>>>> >>>>>>>>>>>> #include "os_family.hpp" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'll try to summarize the final result the way it would look for >>>>>>>>>>>> solaris_sparc: >>>>>>>>>>>> >>>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>>> cpu. >>>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>>> using an api through pd like: >>>>>>>>>>>> >>>>>>>>>>>> doSomething() { >>>>>>>>>>>> os::pd::setup(); >>>>>>>>>>>> do_something(); >>>>>>>>>>>> os::pd::close(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This should enable us to move code from platform specific code >>>>>>>>>>>> (thread creation, signal handling, etc) that look very similar (Linux, Bsd, >>>>>>>>>>>> Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>>>>>> >>>>>>>>>>>> it enables us to have platform specific includes in what >>>>>>>>>>>> os_family.hpp (used to be os_linux.hpp) for platform specific things like >>>>>>>>>>>> semaphores. >>>>>>>>>>>> >>>>>>>>>>>> To show the layout of the files: >>>>>>>>>>>> >>>>>>>>>>>> file: os_family.hpp >>>>>>>>>>>> class osSolaris { >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> typedef osSolaris osCurrent; >>>>>>>>>>>> >>>>>>>>>>>> file: os_cpu.hpp >>>>>>>>>>>> class osSolarisSparc { >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>>>>>> >>>>>>>>>>>> file: os.hpp >>>>>>>>>>>> class os { >>>>>>>>>>>> typedef osCpu cpu; >>>>>>>>>>>> typedef osCurrent pd; >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> Webrevs: >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> /R >>>>>>>>>>>> >>> > From volker.simonis at gmail.com Fri Mar 15 08:52:18 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Mar 2013 16:52:18 +0100 Subject: RFR: NoBugIDYet: Refactoring os classes In-Reply-To: References: <22D2B757-E3CF-43A2-91DA-41C78024D2D1@oracle.com> <514055E6.9050107@oracle.com> <514077A0.2010703@oracle.com> <51407FDE.9070205@oracle.com> <514083A1.6060801@oracle.com> <00F87D1A-8885-4432-AF81-B3D078517B58@oracle.com> <51408D49.4020906@oracle.com> Message-ID: Hi Rickard, the one thing I forgot to mention in my previous mail is that in general I really aprpeciate the refactoring of the os-classes. Although this will cause us a fair amount of work (see Thomas mail) I really think it is worth doing it. Especially the inclusion of the whole os__.hpp files right into the middle of the os class definition is a real PITA (and it breaks modern IDEs as well!). Regards, Volker On Thu, Mar 14, 2013 at 12:05 PM, Rickard B?ckman wrote: > Volker, > > no I haven't tried a lot of IDEs. It seems as if intermediate files are preferred. > > Thanks > /R > > On Mar 14, 2013, at 11:35 AM, Volker Simonis wrote: > >> Have you tested how IDEs (Eclipse, NetBeans) behave if we have >> multiple files with the same name in different locations. At least >> navigation between such files may become unintuitive. In Emacs for >> example it's hard to keep them apart because they get these additional >> numbers in their name ('') which is only based on the order in >> which they were loaded. >> >> So I'd personally also prefer to stay with the old name scheme and use >> intermediate .hpp files. But that's just my personal opinion:) >> >> Volker >> >> On Wed, Mar 13, 2013 at 3:29 PM, Coleen Phillmore >> wrote: >>> >>> On 3/13/2013 10:04 AM, Rickard B?ckman wrote: >>>> >>>> Coleen, >>>> >>>> >>>> On Mar 13, 2013, at 2:48 PM, Coleen Phillmore wrote: >>>> >>>>> Oh, you did pick xnix! I have to confess to not reading the webrevs yet. >>>>> I only glanced at webrev 4. I don't think we can name different files the >>>>> same thing for some historical reason that I can't remember. Does this >>>>> design rely on renaming os_linux.cpp os_family.cpp? I strongly prefer the >>>>> original which is more descriptive. >>>> >>>> Yes, I picked xnix. We can name different files the same thing as long as >>>> only one is part of the compilation (which it will be since the files with >>>> the same names are in different os/ directories). No the design doesn't rely >>>> on renaming os_linux.cpp to os_family.cpp. One thing I would like is to at >>>> least rename the include files (if we really don't want to do that at least >>>> create an intermediate file) to avoid all the >>>> >>>> #if IS_SOLARIS >>>> #include os_solaris.hpp >>>> #elseif IS_LINUX >>>> #include os_linux.hpp >>>> #? >>>> #endif >>> >>> >>> Yes, I was thinking it would be good to have the intermediate .hpp file to >>> avoid the conditional includes for this case instead. >>> >>> Coleen >>> >>>> >>>> Thanks >>>> /R >>>> >>>>> This is good though, it moves along the logjam that was preventing us >>>>> from sharing more code. I'll look at this more later. >>>> >>>> To be able to reduce the amount of duplicated code is one of the main >>>> things I'm trying to address with this change. >>>> >>>> Thanks >>>> /R >>>> >>>>> Coleen >>>>> >>>>> On 3/13/2013 9:38 AM, Rickard B?ckman wrote: >>>>>> >>>>>> That is done in the step4 part of my webrev. :) >>>>>> >>>>>> /R >>>>>> >>>>>> On Mar 13, 2013, at 2:32 PM, Coleen Phillmore wrote: >>>>>> >>>>>>> Your reply below made think maybe we should rename posix directories >>>>>>> and files xnix. >>>>>>> Coleen >>>>>>> >>>>>>> On 3/13/2013 9:11 AM, Rickard B?ckman wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> On Mar 13, 2013, at 1:57 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> On 13/03/2013 9:41 PM, Rickard B?ckman wrote: >>>>>>>>>> >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> On Mar 13, 2013, at 11:33 AM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> Hi Rickard, >>>>>>>>>>> >>>>>>>>>>> An initial comment on your description here: >>>>>>>>>>> >>>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>>> cpu. >>>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>>> using an api through pd like: >>>>>>>>>>>> >>>>>>>>>>>> doSomething() { >>>>>>>>>>>> os::pd::setup(); >>>>>>>>>>>> do_something(); >>>>>>>>>>>> os::pd::close(); >>>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> I don't think the "pd" makes sense because you have to know what >>>>>>>>>>> the "pd" actually is. In old terms an os::Solaris method can call another >>>>>>>>>>> os::Solaris method because it knows it is there. If "pd" is common somehow >>>>>>>>>>> (say pthreads functionality) then that commonality has to be named eg >>>>>>>>>>> os::pthreads, because there might be another commonality related to some >>>>>>>>>>> other aspect of functionality (perhaps Dtrace), so they can't both be called >>>>>>>>>>> "pd". >>>>>>>>>> >>>>>>>>>> So maybe the example here was a bit bad. Maybe this makes more >>>>>>>>>> sense: >>>>>>>>>> >>>>>>>>>> osXnix::suspend_thread(thread) { >>>>>>>>>> ... >>>>>>>>>> os::pd::signal_notify(thread); >>>>>>>>>> ? >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> You still have to know that pd is an interface for one os >>>>>>>>>> platform-dependent API. signal_notify() in this example would be implemented >>>>>>>>>> by pthread_kill on Linux and Bsd, thr_kill on Solaris. Windows wouldn't need >>>>>>>>>> one. >>>>>>>>> >>>>>>>>> But that seems more awkward than what we have now. Now we have >>>>>>>>> os::signal_notify() which is implemented differently for solaris/linux/bsd. >>>>>>>>> That specialization is done via the compile-time include mechanism. With >>>>>>>>> what you suggest the methods that call things like signal_notify now have to >>>>>>>>> know that they are implemented differently on different platforms whereas >>>>>>>>> currently they do not need to know that. >>>>>>>> >>>>>>>> Ah, no. At the moment we have a bunch of things that rely on knowing >>>>>>>> details about os::Bsd, os::Linux (for example jvm_bsd, jvm_linux). We also >>>>>>>> have a lot of code that doesn't care about the details. They use the os:: >>>>>>>> interface. This does however require that all platforms have an >>>>>>>> implementation (empty or not) of whatever is in os:: (unless it is only >>>>>>>> called from some piece of code that is platform specific. In that case I do >>>>>>>> think the code is misplaced though). >>>>>>>> >>>>>>>> That is still the way things should work. However things that >>>>>>>> previously relied on os::Bsd or os::Linux should instead rely on os::pd. >>>>>>>> That would make that code easier to port to new platforms as well as easier >>>>>>>> to at some point unify into code that works for multiple platforms. >>>>>>>> >>>>>>>> os:: is still the main interface to os things. In my example above we >>>>>>>> would have had an >>>>>>>> os::suspend_thread() - that would have had an implementation on all >>>>>>>> platforms. The *nix platforms could use the above implementation and Windows >>>>>>>> another. >>>>>>>> os::suspend_thread() would look like: >>>>>>>> { >>>>>>>> os::pd::suspend_thread(); >>>>>>>> } >>>>>>>> >>>>>>>> instead of having 4 different implementations of suspend_thread, we >>>>>>>> would now have 2. >>>>>>>> >>>>>>>> Hope that makes things clearer. >>>>>>>> >>>>>>>> Thanks >>>>>>>> /R >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Another example taken from os::Bsd >>>>>>>>>> >>>>>>>>>> void os::Bsd::hotspot_sigmask(Thread* thread) { >>>>>>>>>> >>>>>>>>>> //Save caller's signal mask before setting VM signal mask >>>>>>>>>> sigset_t caller_sigmask; >>>>>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>>> >>>>>>>>>> OSThread* osthread = thread->osthread(); >>>>>>>>>> osthread->set_caller_sigmask(caller_sigmask); >>>>>>>>>> >>>>>>>>>> pthread_sigmask(SIG_UNBLOCK, os::Bsd::unblocked_signals(), NULL); >>>>>>>>>> >>>>>>>>>> if (!ReduceSignalUsage) { >>>>>>>>>> if (thread->is_VM_thread()) { >>>>>>>>>> // Only the VM thread handles BREAK_SIGNAL ... >>>>>>>>>> pthread_sigmask(SIG_UNBLOCK, vm_signals(), NULL); >>>>>>>>>> } else { >>>>>>>>>> // ... all other threads block BREAK_SIGNAL >>>>>>>>>> pthread_sigmask(SIG_BLOCK, vm_signals(), NULL); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> could be replaced by an: >>>>>>>>>> >>>>>>>>>> void osXnix::hotspot_sigmask(Thread *thread) { >>>>>>>>>> sigset_t caller_sigmask; >>>>>>>>>> os::pd::thread_sigmask(SIG_BLOCK, NULL, &caller_sigmask); >>>>>>>>>> ? >>>>>>>>>> os::pd::thread_sigmask(?); >>>>>>>>>> ? >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> thread_sigmask would be pthread_sigmask for Bsd, Linux and >>>>>>>>>> thr_setsigmask on Solaris. >>>>>>>>>> >>>>>>>>>> I agree that having yet another level of grouping like >>>>>>>>>> os::signals::sigmask() or os::threads::create_thread() might be a good idea. >>>>>>>>>> I just think that this change is large enough as it is. Further >>>>>>>>>> improvements are always possible. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 13/03/2013 7:50 PM, Rickard B?ckman wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I've spent some time on trying to do some changes to (in my >>>>>>>>>>>> opinion) clean up the os_ files. >>>>>>>>>>>> >>>>>>>>>>>> The change is broken up into 4 web revs to make the changes easier >>>>>>>>>>>> to spot since it involves new files, renaming of files, etc. >>>>>>>>>>>> >>>>>>>>>>>> Step 1) >>>>>>>>>>>> * removes the os::Bsd, os::Linux, etc classes. They are >>>>>>>>>>>> replaced by classes osBsd, osLinux, osPosix (renamed in a later step), etc. >>>>>>>>>>>> * The #include os_name.hpp inside the class definition is >>>>>>>>>>>> moved to before the definition of class os. >>>>>>>>>>>> * Renaming users to the new osBsd, osSolaris, osWindows, >>>>>>>>>>>> osLinux, etc. >>>>>>>>>>>> * Adds a typedef osCurrent pd; inside the os class. >>>>>>>>>>>> >>>>>>>>>>>> Step 2) >>>>>>>>>>>> * Some methods existed in all or almost all >>>>>>>>>>>> os__.hpp, they were moved to os.hpp. >>>>>>>>>>>> >>>>>>>>>>>> Step 3) >>>>>>>>>>>> * Removes os__.hpp and replaces it with a >>>>>>>>>>>> os_cpu.hpp. A new os_cpu.cpp contains the implementations of those methods. >>>>>>>>>>>> * Changes #includes of os__ into #include >>>>>>>>>>>> "os_cpu" >>>>>>>>>>>> * Adds a typedef osCpu cpu; inside the os class. >>>>>>>>>>>> >>>>>>>>>>>> Step 4) >>>>>>>>>>>> * Renames os_posix to os_xnix (xnix is *nix). >>>>>>>>>>>> * Renames os_.ext to os_family.ext >>>>>>>>>>>> * Includes are changed from: >>>>>>>>>>>> >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux >>>>>>>>>>>> # include "os_linux.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_solaris >>>>>>>>>>>> # include "os_solaris.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_windows >>>>>>>>>>>> # include "os_windows.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_bsd >>>>>>>>>>>> # include "os_bsd.hpp" >>>>>>>>>>>> #endif >>>>>>>>>>>> >>>>>>>>>>>> to: >>>>>>>>>>>> >>>>>>>>>>>> #include "os_family.hpp" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'll try to summarize the final result the way it would look for >>>>>>>>>>>> solaris_sparc: >>>>>>>>>>>> >>>>>>>>>>>> There are three classes: osSolaris, osSolarisSparc and os. >>>>>>>>>>>> These are tried together through a couple of typedefs. osSolaris >>>>>>>>>>>> is typedefed to osCurrent and osSolarisSparc is typedefed to osCpu. >>>>>>>>>>>> Inside the os class we now typedef osCurrent to pd and osCpu to >>>>>>>>>>>> cpu. >>>>>>>>>>>> This way we can now access things that was previously accessed >>>>>>>>>>>> through os::Solaris::some_method like: os::pd::some_method. That helps if we >>>>>>>>>>>> want to write some code that would be common for a couple of platforms, >>>>>>>>>>>> using an api through pd like: >>>>>>>>>>>> >>>>>>>>>>>> doSomething() { >>>>>>>>>>>> os::pd::setup(); >>>>>>>>>>>> do_something(); >>>>>>>>>>>> os::pd::close(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This should enable us to move code from platform specific code >>>>>>>>>>>> (thread creation, signal handling, etc) that look very similar (Linux, Bsd, >>>>>>>>>>>> Solaris) into something else that utilizes APIs through os::pd or os::cpu. >>>>>>>>>>>> >>>>>>>>>>>> it enables us to have platform specific includes in what >>>>>>>>>>>> os_family.hpp (used to be os_linux.hpp) for platform specific things like >>>>>>>>>>>> semaphores. >>>>>>>>>>>> >>>>>>>>>>>> To show the layout of the files: >>>>>>>>>>>> >>>>>>>>>>>> file: os_family.hpp >>>>>>>>>>>> class osSolaris { >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> typedef osSolaris osCurrent; >>>>>>>>>>>> >>>>>>>>>>>> file: os_cpu.hpp >>>>>>>>>>>> class osSolarisSparc { >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> typedef osSolarisSparc osCpu; >>>>>>>>>>>> >>>>>>>>>>>> file: os.hpp >>>>>>>>>>>> class os { >>>>>>>>>>>> typedef osCpu cpu; >>>>>>>>>>>> typedef osCurrent pd; >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> Webrevs: >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step1/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step2/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step3/webrev/ >>>>>>>>>>>> http://cr.openjdk.java.net/~rbackman/refactor/step4/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> /R >>>>>>>>>>>> >>> > From coleen.phillimore at oracle.com Fri Mar 15 08:57:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Mar 2013 11:57:40 -0400 Subject: Review Request: 8009614 nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() In-Reply-To: <51431B48.8010803@oracle.com> References: <51422A22.8070408@oracle.com> <51428E57.9080509@oracle.com> <51431B48.8010803@oracle.com> Message-ID: <514344F4.3010801@oracle.com> Looks good. I'm surprised this got through testing. Coleen On 3/15/2013 8:59 AM, Zhengyu Gu wrote: > Thanks! > > -Zhengyu > > On 3/14/2013 10:58 PM, David Holmes wrote: >> On 15/03/2013 5:50 AM, Zhengyu Gu wrote: >>> A simple fix to align up virtual memory allocation size to os defined >>> granularity. >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8009614 >>> Webrev: http://cr.openjdk.java.net/~zgu/8009614/webrev.00/ >> >> Seems reasonable. >> >> David >> ----- >> >>> Test: >>> - Test case: nsk.split_verifier.stress.ifelse002_30.ifelse002 >>> - JPRT >>> >>> >>> Thanks, >>> >>> -Zhengyu > From zhengyu.gu at oracle.com Fri Mar 15 09:05:16 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 15 Mar 2013 12:05:16 -0400 Subject: Review Request: 8009614 nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() In-Reply-To: <514344F4.3010801@oracle.com> References: <51422A22.8070408@oracle.com> <51428E57.9080509@oracle.com> <51431B48.8010803@oracle.com> <514344F4.3010801@oracle.com> Message-ID: <514346BC.2070304@oracle.com> Thank you. -Zhengyu On 3/15/2013 11:57 AM, Coleen Phillimore wrote: > > Looks good. I'm surprised this got through testing. > Coleen > > On 3/15/2013 8:59 AM, Zhengyu Gu wrote: >> Thanks! >> >> -Zhengyu >> >> On 3/14/2013 10:58 PM, David Holmes wrote: >>> On 15/03/2013 5:50 AM, Zhengyu Gu wrote: >>>> A simple fix to align up virtual memory allocation size to os defined >>>> granularity. >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8009614 >>>> Webrev: http://cr.openjdk.java.net/~zgu/8009614/webrev.00/ >>> >>> Seems reasonable. >>> >>> David >>> ----- >>> >>>> Test: >>>> - Test case: nsk.split_verifier.stress.ifelse002_30.ifelse002 >>>> - JPRT >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >> > From stefan.karlsson at oracle.com Fri Mar 15 10:02:01 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 15 Mar 2013 17:02:01 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20130315170228.2018348194@hg.openjdk.java.net> Changeset: 9def4075da6d Author: tamao Date: 2013-03-05 15:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9def4075da6d 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Summary: Update the task local finger to the start of the next object when marking aborts, in order to avoid the redundant scanning of all 0's when the marking task restarts, if otherwise updating to the next word. In addition, reuse the routine nextObject() in routine iterate(). Reviewed-by: johnc, ysr Contributed-by: tamao ! 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 Changeset: 209f8ba5020b Author: tamao Date: 2013-03-07 10:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/209f8ba5020b 8008368: Deprecate MaxGCMinorPauseMillis Summary: Deprecate MaxGCMinorPauseMillis and emit a warning if set by users Reviewed-by: brutisso, johnc Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 1f3354851c91 Author: stefank Date: 2013-03-11 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f3354851c91 Merge Changeset: 167812fe00bb Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/167812fe00bb 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 71f619500f9b Author: kevinw Date: 2013-03-11 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71f619500f9b Merge Changeset: 1c88b99a2b01 Author: mgerdin Date: 2013-03-12 09:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c88b99a2b01 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Summary: Assertion is only valid when at a safepoint, adjust accordingly. Reviewed-by: stefank, jmasa, tamao ! src/share/vm/memory/metaspace.cpp Changeset: ca9580859cf4 Author: stefank Date: 2013-03-11 02:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca9580859cf4 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Summary: Don't scan pages outside the given range. Reviewed-by: jwilhelm, jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: 62609ffa2fc6 Author: tschatzl Date: 2013-03-12 15:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/62609ffa2fc6 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: eac371996b44 Author: brutisso Date: 2013-03-12 08:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eac371996b44 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Summary: Take the initial heap size into account when checking the heap size for compressed oops Reviewed-by: jmasa, kvn, hseigel, ctornqvi ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 993d878108d9 Author: brutisso Date: 2013-03-13 05:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/993d878108d9 Merge Changeset: 82657b6a8cc0 Author: jmasa Date: 2013-03-12 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82657b6a8cc0 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp Changeset: 15401203db6b Author: stefank Date: 2013-03-15 08:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/15401203db6b Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a10dc1469c3f Author: stefank Date: 2013-03-15 04:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a10dc1469c3f Merge From christian.thalinger at oracle.com Fri Mar 15 10:12:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 15 Mar 2013 10:12:41 -0700 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <5142BDDF.9040907@oracle.com> References: <5142BDDF.9040907@oracle.com> Message-ID: <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> Looks good to me. -- Chris On Mar 14, 2013, at 11:21 PM, David Holmes wrote: > The CR for this is not public. These are just some renamings of our JPRT build targets. > > http://cr.openjdk.java.net/~dholmes/8008783/webrev/ > > This will be pushed via hotspot-emb once some internal changes are in place to deal with the new names. > > I will need a hotspot Reviewer for this please. (You know who you are! ;-)) > > Thanks, > David From John.Coomes at oracle.com Fri Mar 15 13:19:27 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 15 Mar 2013 13:19:27 -0700 Subject: a changeset was removed from hsx/hotspot-emb/hotspot - get a new clone Message-ID: <20803.33359.277129.941337@oracle.com> Everyone with a clone of http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot that includes this changeset: changeset: 4267:29ab68ef5bb6 tag: tip user: jprovino date: Wed Mar 13 10:34:10 2013 -0400 summary: 8009004: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm must save any work in progress as a patch, delete your clone, get a new clone and reapply your patch. The changeset was removed from the repository and has been blacklisted on hg.openjdk.java.net. -John From bob.vandette at oracle.com Fri Mar 15 14:06:09 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 15 Mar 2013 17:06:09 -0400 Subject: a changeset was removed from hsx/hotspot-emb/hotspot - get a new clone In-Reply-To: <20803.33359.277129.941337@oracle.com> References: <20803.33359.277129.941337@oracle.com> Message-ID: <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> What about JPRT jobs in the queue? Do I need to kill it and start over? Bob. On Mar 15, 2013, at 4:19 PM, John Coomes wrote: > Everyone with a clone of > > http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot > > that includes this changeset: > > changeset: 4267:29ab68ef5bb6 > tag: tip > user: jprovino > date: Wed Mar 13 10:34:10 2013 -0400 > summary: 8009004: jvmtiClassFileReconstituter.cpp needs to > be excluded from the minimal jvm > > must save any work in progress as a patch, delete your clone, get a > new clone and reapply your patch. > > The changeset was removed from the repository and has been blacklisted > on hg.openjdk.java.net. > > -John From daniel.daugherty at oracle.com Fri Mar 15 14:33:45 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2013 15:33:45 -0600 Subject: a changeset was removed from hsx/hotspot-emb/hotspot - get a new clone In-Reply-To: <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> References: <20803.33359.277129.941337@oracle.com> <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> Message-ID: <514393B9.9080906@oracle.com> Doesn't look like your job has the bad changeset: $ hg -R /net/prt-archiver.us.oracle.com/data/jprt/archiv e/2013/03/2013-03-15-211744.bvandett.hotspot/sourcetree log -r 29ab68ef5bb6 abort: unknown revision '29ab68ef5bb6'! $ hg -R /net/prt-archiver.us.oracle.com/data/jprt/archive/2013/03/2013-03-15-211744.bvandett.hotspot/sourcetree log | grep 8009004 Dan On 3/15/13 3:06 PM, Bob Vandette wrote: > What about JPRT jobs in the queue? > > Do I need to kill it and start over? > > Bob. > > > On Mar 15, 2013, at 4:19 PM, John Coomes wrote: > >> Everyone with a clone of >> >> http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot >> >> that includes this changeset: >> >> changeset: 4267:29ab68ef5bb6 >> tag: tip >> user: jprovino >> date: Wed Mar 13 10:34:10 2013 -0400 >> summary: 8009004: jvmtiClassFileReconstituter.cpp needs to >> be excluded from the minimal jvm >> >> must save any work in progress as a patch, delete your clone, get a >> new clone and reapply your patch. >> >> The changeset was removed from the repository and has been blacklisted >> on hg.openjdk.java.net. >> >> -John From John.Coomes at oracle.com Fri Mar 15 15:03:40 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 15 Mar 2013 15:03:40 -0700 Subject: a changeset was removed from hsx/hotspot-emb/hotspot - get a new clone In-Reply-To: <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> References: <20803.33359.277129.941337@oracle.com> <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> Message-ID: <20803.39612.660812.201815@oracle.com> Bob Vandette (bob.vandette at oracle.com) wrote: > What about JPRT jobs in the queue? > > Do I need to kill it and start over? If your job will push changesets, and the cset below is included in your repo, then you have to kill it and start over. -John > On Mar 15, 2013, at 4:19 PM, John Coomes wrote: > > > Everyone with a clone of > > > > http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot > > > > that includes this changeset: > > > > changeset: 4267:29ab68ef5bb6 > > tag: tip > > user: jprovino > > date: Wed Mar 13 10:34:10 2013 -0400 > > summary: 8009004: jvmtiClassFileReconstituter.cpp needs to > > be excluded from the minimal jvm > > > > must save any work in progress as a patch, delete your clone, get a > > new clone and reapply your patch. > > > > The changeset was removed from the repository and has been blacklisted > > on hg.openjdk.java.net. > > > > -John > From vladimir.kozlov at oracle.com Fri Mar 15 15:08:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Mar 2013 15:08:14 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: <51439BCE.2060606@oracle.com> Why do you need a switch in next code in LibraryCallKit::inline_native_Reflection_getCallerClass()? I don't think you need to match JVM_GetCallerClass code one-to-one. You don't have =0 case and the check for =1 could be done before loop. It will simplify code. Adjust next comment to reference JVM_GetCallerClass: // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass) I think in JVM_GetCallerClass() you can use intrinsic_id: m->intrinsic_id() == vmIntrinsics::_getCallerClass Thanks, Vladimir On 3/14/13 8:31 PM, Christian Thalinger wrote: > [This is the HotSpot part of JEP 176] > > http://cr.openjdk.java.net/~twisti/7198429 > > 7198429: need checked categorization of caller-sensitive methods in the JDK > Reviewed-by: > > More information in JEP 176: > > http://openjdk.java.net/jeps/176 > > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/classFileParser.hpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/oops/method.cpp > src/share/vm/oops/method.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/prims/jvm.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/prims/unsafe.cpp > src/share/vm/runtime/vframe.cpp > src/share/vm/runtime/vframe.hpp > From alejandro.murillo at oracle.com Fri Mar 15 15:29:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Mar 2013 22:29:36 +0000 Subject: hg: hsx/hsx25/hotspot: 48 new changesets Message-ID: <20130315223121.2DBAB481A7@hg.openjdk.java.net> Changeset: f1629878512f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f1629878512f Added tag jdk8-b81 for changeset 65b797426a3b ! .hgtags Changeset: b95ad0610fef Author: asaha Date: 2012-10-26 09:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b95ad0610fef Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 77443715ec55 Author: kamg Date: 2012-11-05 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/77443715ec55 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: b5cb079ecaa4 Author: ewendeli Date: 2013-02-03 22:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5cb079ecaa4 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1cabf9c80e84 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1cabf9c80e84 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d4a32a6f8c82 Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d4a32a6f8c82 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 11d5942ef9c7 Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/11d5942ef9c7 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ee744831dcb Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ee744831dcb Merge Changeset: 8196357e95b5 Author: amurillo Date: 2013-03-08 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8196357e95b5 8009688: new hotspot build - hs25-b23 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 255c0a4cb4eb Author: sla Date: 2013-03-05 08:50 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/255c0a4cb4eb 8009287: [parfait] Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Reviewed-by: dholmes, kvn, mikael, morris ! agent/src/os/linux/ps_core.c Changeset: 9058789475af Author: iklam Date: 2013-03-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9058789475af 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu Contributed-by: ioi.lam at oracle.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c Changeset: 6b803ba47588 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b803ba47588 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 3efdfd6ddbf2 Author: coleenp Date: 2013-03-08 11:47 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3efdfd6ddbf2 8003553: NPG: metaspace objects should be zeroed in constructors Summary: Zero metadata in constructors, not in allocation (and some in constructors) Reviewed-by: jmasa, sspitsyn ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 252ad8d5f22b Author: dcubed Date: 2013-03-08 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/252ad8d5f22b Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 35ef86296a5d Author: dcubed Date: 2013-03-08 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/35ef86296a5d Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 5939f5953b45 Author: coleenp Date: 2013-03-13 09:10 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5939f5953b45 8009836: nsk/regression/b4222717 fails with empty stack trace Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcom crashes, add back zeroing to metablock Reviewed-by: dholmes, rbackman ! src/share/vm/memory/metablock.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/method.cpp Changeset: 96480359523a Author: coleenp Date: 2013-03-11 14:00 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/96480359523a 8008965: @Contended fails with classes having static fields Summary: Disable @Contended support for static fields Reviewed-by: coleenp, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp + test/runtime/8003985/Test8003985.java Changeset: d6320e955c89 Author: coleenp Date: 2013-03-13 13:47 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d6320e955c89 Merge Changeset: 0ede345ec7c9 Author: coleenp Date: 2013-03-13 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0ede345ec7c9 8009829: CDS: JDK JPRT test fails crash in Symbol::equals() Summary: -Xshare:dump was creating a Symbol in C_heap. There's an assert there that jdk jprt wasn't hitting because it was only done in product Reviewed-by: dholmes, hseigel, iklam ! src/share/vm/classfile/symbolTable.cpp Changeset: c8b31b461e1a Author: coleenp Date: 2013-03-13 17:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c8b31b461e1a 8003419: NPG: Clean up metadata created during class loading if failure Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. Reviewed-by: jmasa, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: fad90b102190 Author: jprovino Date: 2013-03-06 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fad90b102190 8008310: Some adjustments needed to minimal VM warnings and errors for unsupported command line options Summary: Changes to arguments.cpp for warnings vs. errors. Changes for CDS arguments. Reviewed-by: coleenp, cjplummer ! make/excludeSrc.make ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 47bc9800972c Author: jprovino Date: 2013-03-06 13:46 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/47bc9800972c 8006498: #if is wrong in the code. Summary: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not. Reviewed-by: dholmes, mikael ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiTrace.hpp Changeset: 67342b960b47 Author: jprovino Date: 2013-03-06 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/67342b960b47 8008474: Add -Wundef to warning flags. Summary: Force use of undefined macros to be and error. Reviewed-by: dholmes, mikael ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: cb75b67f04fb Author: jprovino Date: 2013-03-08 12:35 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cb75b67f04fb Merge ! make/bsd/makefiles/gcc.make Changeset: 69ffa4ac9e53 Author: jprovino Date: 2013-03-12 00:02 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69ffa4ac9e53 8009835: Only produce a warning when -Xshare:auto is explicitly requested Summary: The minimal JVM is printing a warning message for default settings when it should quitely ignore them. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 9102c4111564 Author: jprovino Date: 2013-03-14 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9102c4111564 Merge Changeset: ed53b50794d7 Author: vladidan Date: 2013-03-14 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed53b50794d7 Merge Changeset: 0094485b46c7 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0094485b46c7 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: 056ab43544a4 Author: neliasso Date: 2013-03-13 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/056ab43544a4 8009721: Make PhaseLive independent from regalloc Summary: Moved class definition of LRG_List from chaitin.hpp to live.hpp Reviewed-by: kvn, rbackman, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/live.hpp Changeset: 6d98efabf3ba Author: neliasso Date: 2013-03-13 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6d98efabf3ba Merge Changeset: b7c2c5b2572c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b7c2c5b2572c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp Changeset: 71f13276159d Author: morris Date: 2013-03-14 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/71f13276159d 8008560: [parfait] Null pointer deference in hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Summary: add null pointer check in signal handler Reviewed-by: kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: fba788946616 Author: morris Date: 2013-03-14 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fba788946616 Merge Changeset: 9def4075da6d Author: tamao Date: 2013-03-05 15:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9def4075da6d 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Summary: Update the task local finger to the start of the next object when marking aborts, in order to avoid the redundant scanning of all 0's when the marking task restarts, if otherwise updating to the next word. In addition, reuse the routine nextObject() in routine iterate(). Reviewed-by: johnc, ysr Contributed-by: tamao ! 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 Changeset: 209f8ba5020b Author: tamao Date: 2013-03-07 10:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/209f8ba5020b 8008368: Deprecate MaxGCMinorPauseMillis Summary: Deprecate MaxGCMinorPauseMillis and emit a warning if set by users Reviewed-by: brutisso, johnc Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 1f3354851c91 Author: stefank Date: 2013-03-11 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f3354851c91 Merge Changeset: 167812fe00bb Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/167812fe00bb 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 71f619500f9b Author: kevinw Date: 2013-03-11 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/71f619500f9b Merge Changeset: 1c88b99a2b01 Author: mgerdin Date: 2013-03-12 09:42 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c88b99a2b01 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Summary: Assertion is only valid when at a safepoint, adjust accordingly. Reviewed-by: stefank, jmasa, tamao ! src/share/vm/memory/metaspace.cpp Changeset: ca9580859cf4 Author: stefank Date: 2013-03-11 02:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca9580859cf4 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Summary: Don't scan pages outside the given range. Reviewed-by: jwilhelm, jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: 62609ffa2fc6 Author: tschatzl Date: 2013-03-12 15:10 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/62609ffa2fc6 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: eac371996b44 Author: brutisso Date: 2013-03-12 08:33 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eac371996b44 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Summary: Take the initial heap size into account when checking the heap size for compressed oops Reviewed-by: jmasa, kvn, hseigel, ctornqvi ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 993d878108d9 Author: brutisso Date: 2013-03-13 05:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/993d878108d9 Merge Changeset: 82657b6a8cc0 Author: jmasa Date: 2013-03-12 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82657b6a8cc0 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp Changeset: 15401203db6b Author: stefank Date: 2013-03-15 08:57 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/15401203db6b Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a10dc1469c3f Author: stefank Date: 2013-03-15 04:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a10dc1469c3f Merge Changeset: 0631ebcc45f0 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0631ebcc45f0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3db4ab0e12f4 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3db4ab0e12f4 Added tag hs25-b23 for changeset 0631ebcc45f0 ! .hgtags From bob.vandette at oracle.com Fri Mar 15 15:59:06 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 15 Mar 2013 18:59:06 -0400 Subject: a changeset was removed from hsx/hotspot-emb/hotspot - get a new clone In-Reply-To: <514393B9.9080906@oracle.com> References: <20803.33359.277129.941337@oracle.com> <6B9A8756-C1B4-4281-A38A-C1AFEAD6D988@oracle.com> <514393B9.9080906@oracle.com> Message-ID: That's the new one. I killed the original one which had it. Thanks, Bob. On Mar 15, 2013, at 5:33 PM, Daniel D. Daugherty wrote: > Doesn't look like your job has the bad changeset: > > $ hg -R /net/prt-archiver.us.oracle.com/data/jprt/archiv > e/2013/03/2013-03-15-211744.bvandett.hotspot/sourcetree log -r 29ab68ef5bb6 > abort: unknown revision '29ab68ef5bb6'! > > $ hg -R /net/prt-archiver.us.oracle.com/data/jprt/archive/2013/03/2013-03-15-211744.bvandett.hotspot/sourcetree log | grep 8009004 > > > Dan > > > On 3/15/13 3:06 PM, Bob Vandette wrote: >> What about JPRT jobs in the queue? >> >> Do I need to kill it and start over? >> >> Bob. >> >> >> On Mar 15, 2013, at 4:19 PM, John Coomes wrote: >> >>> Everyone with a clone of >>> >>> http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot >>> >>> that includes this changeset: >>> >>> changeset: 4267:29ab68ef5bb6 >>> tag: tip >>> user: jprovino >>> date: Wed Mar 13 10:34:10 2013 -0400 >>> summary: 8009004: jvmtiClassFileReconstituter.cpp needs to >>> be excluded from the minimal jvm >>> >>> must save any work in progress as a patch, delete your clone, get a >>> new clone and reapply your patch. >>> >>> The changeset was removed from the repository and has been blacklisted >>> on hg.openjdk.java.net. >>> >>> -John > From christian.thalinger at oracle.com Fri Mar 15 17:53:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 15 Mar 2013 17:53:16 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <51439BCE.2060606@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <51439BCE.2060606@oracle.com> Message-ID: On Mar 15, 2013, at 3:08 PM, Vladimir Kozlov wrote: > Why do you need a switch in next code in LibraryCallKit::inline_native_Reflection_getCallerClass()? > I don't think you need to match JVM_GetCallerClass code one-to-one. You don't have =0 case and the check for =1 could be done before loop. It will simplify code. Yes it would but I want to keep the code as similar as possible to make future changes easier. If I could I would factor the code to a method but that doesn't work very well. I'd like to keep it as it is. > > Adjust next comment to reference JVM_GetCallerClass: > > // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass) There is a comment right before the loop: // Cf. JVM_GetCallerClass but I can add this one too. > > > I think in JVM_GetCallerClass() you can use intrinsic_id: > > m->intrinsic_id() == vmIntrinsics::_getCallerClass You're right. I missed that. Then I can undo the reflect_Reflection_klass change. The webrev is updated: http://cr.openjdk.java.net/~twisti/7198429/ -- Chris > > Thanks, > Vladimir > > On 3/14/13 8:31 PM, Christian Thalinger wrote: >> [This is the HotSpot part of JEP 176] >> >> http://cr.openjdk.java.net/~twisti/7198429 >> >> 7198429: need checked categorization of caller-sensitive methods in the JDK >> Reviewed-by: >> >> More information in JEP 176: >> >> http://openjdk.java.net/jeps/176 >> >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciMethod.hpp >> src/share/vm/classfile/classFileParser.cpp >> src/share/vm/classfile/classFileParser.hpp >> src/share/vm/classfile/javaClasses.hpp >> src/share/vm/classfile/systemDictionary.hpp >> src/share/vm/classfile/vmSymbols.hpp >> src/share/vm/oops/method.cpp >> src/share/vm/oops/method.hpp >> src/share/vm/opto/library_call.cpp >> src/share/vm/prims/jvm.cpp >> src/share/vm/prims/methodHandles.cpp >> src/share/vm/prims/unsafe.cpp >> src/share/vm/runtime/vframe.cpp >> src/share/vm/runtime/vframe.hpp >> From vladimir.kozlov at oracle.com Fri Mar 15 18:04:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Mar 2013 18:04:24 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <51439BCE.2060606@oracle.com> Message-ID: <5143C518.7060406@oracle.com> Good. Vladimir On 3/15/13 5:53 PM, Christian Thalinger wrote: > > On Mar 15, 2013, at 3:08 PM, Vladimir Kozlov wrote: > >> Why do you need a switch in next code in LibraryCallKit::inline_native_Reflection_getCallerClass()? >> I don't think you need to match JVM_GetCallerClass code one-to-one. You don't have =0 case and the check for =1 could be done before loop. It will simplify code. > > Yes it would but I want to keep the code as similar as possible to make future changes easier. If I could I would factor the code to a method but that doesn't work very well. I'd like to keep it as it is. > >> >> Adjust next comment to reference JVM_GetCallerClass: >> >> // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass) > > There is a comment right before the loop: > > // Cf. JVM_GetCallerClass > > but I can add this one too. > >> >> >> I think in JVM_GetCallerClass() you can use intrinsic_id: >> >> m->intrinsic_id() == vmIntrinsics::_getCallerClass > > You're right. I missed that. Then I can undo the reflect_Reflection_klass change. > > The webrev is updated: > > http://cr.openjdk.java.net/~twisti/7198429/ > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 3/14/13 8:31 PM, Christian Thalinger wrote: >>> [This is the HotSpot part of JEP 176] >>> >>> http://cr.openjdk.java.net/~twisti/7198429 >>> >>> 7198429: need checked categorization of caller-sensitive methods in the JDK >>> Reviewed-by: >>> >>> More information in JEP 176: >>> >>> http://openjdk.java.net/jeps/176 >>> >>> src/share/vm/ci/ciMethod.cpp >>> src/share/vm/ci/ciMethod.hpp >>> src/share/vm/classfile/classFileParser.cpp >>> src/share/vm/classfile/classFileParser.hpp >>> src/share/vm/classfile/javaClasses.hpp >>> src/share/vm/classfile/systemDictionary.hpp >>> src/share/vm/classfile/vmSymbols.hpp >>> src/share/vm/oops/method.cpp >>> src/share/vm/oops/method.hpp >>> src/share/vm/opto/library_call.cpp >>> src/share/vm/prims/jvm.cpp >>> src/share/vm/prims/methodHandles.cpp >>> src/share/vm/prims/unsafe.cpp >>> src/share/vm/runtime/vframe.cpp >>> src/share/vm/runtime/vframe.hpp >>> > From christian.thalinger at oracle.com Fri Mar 15 18:08:12 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 15 Mar 2013 18:08:12 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5143C518.7060406@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <51439BCE.2060606@oracle.com> <5143C518.7060406@oracle.com> Message-ID: <74F146F2-78AB-481E-8F2E-9286EB300F31@oracle.com> On Mar 15, 2013, at 6:04 PM, Vladimir Kozlov wrote: > Good. Thank you, Vladimir. -- Chris > > Vladimir > > On 3/15/13 5:53 PM, Christian Thalinger wrote: >> >> On Mar 15, 2013, at 3:08 PM, Vladimir Kozlov wrote: >> >>> Why do you need a switch in next code in LibraryCallKit::inline_native_Reflection_getCallerClass()? >>> I don't think you need to match JVM_GetCallerClass code one-to-one. You don't have =0 case and the check for =1 could be done before loop. It will simplify code. >> >> Yes it would but I want to keep the code as similar as possible to make future changes easier. If I could I would factor the code to a method but that doesn't work very well. I'd like to keep it as it is. >> >>> >>> Adjust next comment to reference JVM_GetCallerClass: >>> >>> // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass) >> >> There is a comment right before the loop: >> >> // Cf. JVM_GetCallerClass >> >> but I can add this one too. >> >>> >>> >>> I think in JVM_GetCallerClass() you can use intrinsic_id: >>> >>> m->intrinsic_id() == vmIntrinsics::_getCallerClass >> >> You're right. I missed that. Then I can undo the reflect_Reflection_klass change. >> >> The webrev is updated: >> >> http://cr.openjdk.java.net/~twisti/7198429/ >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> On 3/14/13 8:31 PM, Christian Thalinger wrote: >>>> [This is the HotSpot part of JEP 176] >>>> >>>> http://cr.openjdk.java.net/~twisti/7198429 >>>> >>>> 7198429: need checked categorization of caller-sensitive methods in the JDK >>>> Reviewed-by: >>>> >>>> More information in JEP 176: >>>> >>>> http://openjdk.java.net/jeps/176 >>>> >>>> src/share/vm/ci/ciMethod.cpp >>>> src/share/vm/ci/ciMethod.hpp >>>> src/share/vm/classfile/classFileParser.cpp >>>> src/share/vm/classfile/classFileParser.hpp >>>> src/share/vm/classfile/javaClasses.hpp >>>> src/share/vm/classfile/systemDictionary.hpp >>>> src/share/vm/classfile/vmSymbols.hpp >>>> src/share/vm/oops/method.cpp >>>> src/share/vm/oops/method.hpp >>>> src/share/vm/opto/library_call.cpp >>>> src/share/vm/prims/jvm.cpp >>>> src/share/vm/prims/methodHandles.cpp >>>> src/share/vm/prims/unsafe.cpp >>>> src/share/vm/runtime/vframe.cpp >>>> src/share/vm/runtime/vframe.hpp >>>> >> From alejandro.murillo at oracle.com Fri Mar 15 18:27:37 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 16 Mar 2013 01:27:37 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130316012801.2D6F3481AF@hg.openjdk.java.net> Changeset: f1629878512f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1629878512f Added tag jdk8-b81 for changeset 65b797426a3b ! .hgtags Changeset: b95ad0610fef Author: asaha Date: 2012-10-26 09:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b95ad0610fef Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 77443715ec55 Author: kamg Date: 2012-11-05 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/77443715ec55 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: b5cb079ecaa4 Author: ewendeli Date: 2013-02-03 22:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5cb079ecaa4 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1cabf9c80e84 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1cabf9c80e84 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d4a32a6f8c82 Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d4a32a6f8c82 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 11d5942ef9c7 Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11d5942ef9c7 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ee744831dcb Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ee744831dcb Merge Changeset: 0631ebcc45f0 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0631ebcc45f0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3db4ab0e12f4 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3db4ab0e12f4 Added tag hs25-b23 for changeset 0631ebcc45f0 ! .hgtags Changeset: 7ae04e71af90 Author: amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Mon Mar 18 03:27:28 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Mar 2013 10:27:28 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp> <50CFB788.7080106@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp> <50D05112.70506@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> Hi, I want to take up this issue again. I think we gave a good reason for the fence we added in the taskqueue. Do you have any remaining objections against this change? We are happy to discuss or adapt the change. If not, could somebody please push this change to hotspot? http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ Best regards, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Freitag, 8. M?rz 2013 17:13 To: Volker Simonis Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker Subject: Re: RFR(M): Memory ordering in taskqueue.hpp I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). Sent from my phone On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > wrote: > Hi Vitaly, > > the writer has a sync after the write to bottom (see pop_local) > but the store and the sync are not one atomic operation. Stuff > can happen before the sync is executed. Therefore the reader > must sync, too. > Exactly - you have three threads. The first one executes the write to bottom but not the following sync. The second thread reads this new value (by chance) and uses it but the third thread still sees the old value because there's no multipl-copy-atomicity on PPC. So we really need the sync before the read to assure thread three is not seeing an older value than thread two. > Anyways, in pop_global it should be cheaper than in pop_local. > > Best regards, > Geotz. > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: Freitag, 8. M?rz 2013 16:13 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. > > Thanks > > Sent from my phone > On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: > Hi Vitaly, > > No, the problem is not reordering. The problem is that > _bottom, which is read after _age, might be older than _age because > another processor didn't write it back yet. The fence (sync) makes the > current thread wait until it has the new _bottom. > On Power, a write is not visible to all other threads simultaneously > (no multipl-copy-atomicity). > > What you propose helps if you look at two processors, but not if > four threads on four processors are involved. > > Best regards, > Goetz. > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] > Sent: Freitag, 8. M?rz 2013 15:29 > To: Lindenmaier, Goetz > Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker > Subject: RE: RFR(M): Memory ordering in taskqueue.hpp > > > Hi Goetz, > > If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? > > Thanks > > Sent from my phone > On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: > Hi, > > we have been, and still are, doing research on this issue. > We want to keep you up to date on this, and propose on the > further proceeding. > > You asked explicit memory ordering operations and a rationale > why we added them. > > Axel found a paper describing the task queue algorithm and the > needed ordering on arm and power: > Correct and Efficient Work-Stealing for Weak Memory Models; > L?, Pop, Cohen, Nardelli; PPoPP'13; > http://www.di.ens.fr/~zappa/readings/ppopp13.pdf > > According to this paper we need to add one fence and one load_acquire > to your implementation of the task queue. You find this fence in this small > webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > With this fence, the algorithm works on Linux for our openjdk ppc > port, and also for our SAP JVM . > > Actually, the fence fixes a problem we discovered with the concurrency > torture test suite. The problem occurs with four or more GC threads. > If three threads are stealing from the queue of the fourth, two of > them can pop the same element. Without a fence between the access > to age and bottom in pop_global(), bottom can be older than age. > > > Unfortunately, the OpenJDK implementation with the added fence > does not work on AIX. Axel already detected one place where the xlC > compiler optimization removed load instruction that is required for > the correctness of the algorithm. If we use our access routines with load_acquire > (see original webrev below) everything works, unclear why. > > Now, we think C++ might allow that this load is removed and xlC does > the correct, but unexpected thing. On the other hand it might also be > a compiler bug. > We are currently discussing this with the IBM xlC developers. > > Best regards, > Axel and Goetz. > > > PS: The webrev we proposed originally: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ > > > > > > From staffan.larsen at oracle.com Mon Mar 18 06:13:22 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Mar 2013 14:13:22 +0100 Subject: =?iso-8859-1?Q?Result=3A_CFV=3A_New_HSX_Committer=3A_Markus_Gr?= =?iso-8859-1?Q?=F6nlund?= Message-ID: <588B4499-5A3F-4BD4-B54C-EEC786BB8E9B@oracle.com> Voting for Markus Gr?nlund is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Staffan From erik.helin at oracle.com Mon Mar 18 06:43:10 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Mon, 18 Mar 2013 13:43:10 +0000 Subject: hg: hsx/hsx24/hotspot: 8009232: Improve stats gathering code for reference processor Message-ID: <20130318134314.3A25F4820D@hg.openjdk.java.net> Changeset: e99b6a69b81d Author: ehelin Date: 2013-03-18 12:29 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e99b6a69b81d 8009232: Improve stats gathering code for reference processor Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/referenceProcessorStats.hpp ! src/share/vm/trace/trace.xml From erik.helin at oracle.com Mon Mar 18 09:42:03 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Mon, 18 Mar 2013 16:42:03 +0000 Subject: hg: hsx/hsx24/hotspot: 8008918: Reference statistics events for the tracing framework Message-ID: <20130318164207.65AC648216@hg.openjdk.java.net> Changeset: c49a43256225 Author: ehelin Date: 2013-03-18 15:06 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c49a43256225 8008918: Reference statistics events for the tracing framework Reviewed-by: jwilhelm, brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp From john.cuthbertson at oracle.com Mon Mar 18 10:55:33 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 18 Mar 2013 10:55:33 -0700 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> Message-ID: <51475515.9050908@oracle.com> Hi Geotz, I have a patch that I synthesized from yours that I gave to one our engineers who is working on PowerPC. He was seeing crashes before applying your patch and mine. With either patch applied, the crashes disappear. The only real difference between our patches is that I only ordered access to the _bottom field and left accesses to the _age field (and it's sub fields) unordered. If I give you my patch do you think you could test with it? It might take a day or two as I want to get the fixes for the G1 marking bugs committed - the stability of G1 is my highest priority. BTW - whatever patch is committed - I intend to make you the contributor. Cheers, JohnC On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: > Hi, > > I want to take up this issue again. > I think we gave a good reason for the fence we added in the taskqueue. > Do you have any remaining objections against this change? We are > happy to discuss or adapt the change. > If not, could somebody please push this change to hotspot? > > http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > Best regards, > Goetz. > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: Freitag, 8. M?rz 2013 17:13 > To: Volker Simonis > Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > > I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). > > Sent from my phone > On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > > wrote: >> Hi Vitaly, >> >> the writer has a sync after the write to bottom (see pop_local) >> but the store and the sync are not one atomic operation. Stuff >> can happen before the sync is executed. Therefore the reader >> must sync, too. >> > Exactly - you have three threads. The first one executes the write > to bottom but not the following sync. The second thread reads this > new value (by chance) and uses it but the third thread still sees the > old value because there's no multipl-copy-atomicity on PPC. So we > really need the sync before the read to assure thread three is not seeing > an older value than thread two. > >> Anyways, in pop_global it should be cheaper than in pop_local. >> >> Best regards, >> Geotz. >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 16:13 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >> Hi Vitaly, >> >> No, the problem is not reordering. The problem is that >> _bottom, which is read after _age, might be older than _age because >> another processor didn't write it back yet. The fence (sync) makes the >> current thread wait until it has the new _bottom. >> On Power, a write is not visible to all other threads simultaneously >> (no multipl-copy-atomicity). >> >> What you propose helps if you look at two processors, but not if >> four threads on four processors are involved. >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >> Sent: Freitag, 8. M?rz 2013 15:29 >> To: Lindenmaier, Goetz >> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hi Goetz, >> >> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >> Hi, >> >> we have been, and still are, doing research on this issue. >> We want to keep you up to date on this, and propose on the >> further proceeding. >> >> You asked explicit memory ordering operations and a rationale >> why we added them. >> >> Axel found a paper describing the task queue algorithm and the >> needed ordering on arm and power: >> Correct and Efficient Work-Stealing for Weak Memory Models; >> L?, Pop, Cohen, Nardelli; PPoPP'13; >> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >> >> According to this paper we need to add one fence and one load_acquire >> to your implementation of the task queue. You find this fence in this small >> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> With this fence, the algorithm works on Linux for our openjdk ppc >> port, and also for our SAP JVM . >> >> Actually, the fence fixes a problem we discovered with the concurrency >> torture test suite. The problem occurs with four or more GC threads. >> If three threads are stealing from the queue of the fourth, two of >> them can pop the same element. Without a fence between the access >> to age and bottom in pop_global(), bottom can be older than age. >> >> >> Unfortunately, the OpenJDK implementation with the added fence >> does not work on AIX. Axel already detected one place where the xlC >> compiler optimization removed load instruction that is required for >> the correctness of the algorithm. If we use our access routines with load_acquire >> (see original webrev below) everything works, unclear why. >> >> Now, we think C++ might allow that this load is removed and xlC does >> the correct, but unexpected thing. On the other hand it might also be >> a compiler bug. >> We are currently discussing this with the IBM xlC developers. >> >> Best regards, >> Axel and Goetz. >> >> >> PS: The webrev we proposed originally: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >> >> >> >> >> >> From david.holmes at oracle.com Mon Mar 18 14:15:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 07:15:09 +1000 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <5142BDDF.9040907@oracle.com> References: <5142BDDF.9040907@oracle.com> Message-ID: <514783DD.1050206@oracle.com> Need a Reviewer please. David On 15/03/2013 4:21 PM, David Holmes wrote: > The CR for this is not public. These are just some renamings of our JPRT > build targets. > > http://cr.openjdk.java.net/~dholmes/8008783/webrev/ > > This will be pushed via hotspot-emb once some internal changes are in > place to deal with the new names. > > I will need a hotspot Reviewer for this please. (You know who you are! ;-)) > > Thanks, > David From david.holmes at oracle.com Mon Mar 18 14:17:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 07:17:07 +1000 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> References: <5142BDDF.9040907@oracle.com> <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> Message-ID: <51478453.9040202@oracle.com> Thanks Chris. Please ignore my previous email seeking a Reviewer. I hadn't realized you were a Reviewer. Still need a second reviewer though. David On 16/03/2013 3:12 AM, Christian Thalinger wrote: > Looks good to me. -- Chris > > On Mar 14, 2013, at 11:21 PM, David Holmes wrote: > >> The CR for this is not public. These are just some renamings of our JPRT build targets. >> >> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >> >> This will be pushed via hotspot-emb once some internal changes are in place to deal with the new names. >> >> I will need a hotspot Reviewer for this please. (You know who you are! ;-)) >> >> Thanks, >> David > From gary.collins at oracle.com Mon Mar 18 14:20:15 2013 From: gary.collins at oracle.com (Gary Collins) Date: Mon, 18 Mar 2013 14:20:15 -0700 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <514783DD.1050206@oracle.com> References: <5142BDDF.9040907@oracle.com> <514783DD.1050206@oracle.com> Message-ID: Looks good to me.. I guess I'll need to make the change in 7 as well. Thanks Gary On Mar 18, 2013, at 2:15 PM, David Holmes wrote: > Need a Reviewer please. > > David > > On 15/03/2013 4:21 PM, David Holmes wrote: >> The CR for this is not public. These are just some renamings of our JPRT >> build targets. >> >> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >> >> This will be pushed via hotspot-emb once some internal changes are in >> place to deal with the new names. >> >> I will need a hotspot Reviewer for this please. (You know who you are! ;-)) >> >> Thanks, >> David From morris.meyer at oracle.com Fri Mar 8 05:57:28 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Fri, 08 Mar 2013 13:57:28 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130308135749.B02CC48007@hg.openjdk.java.net> Changeset: 40b7c6b800ab Author: morris Date: 2013-03-01 14:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/40b7c6b800ab 8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m Summary: Fix unitialized variable and return value. Reviewed-by: kvn ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: bf06968a8a00 Author: morris Date: 2013-03-04 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf06968a8a00 8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value Summary: safety checks for non-Apple thread time functions Reviewed-by: kvn ! src/os/bsd/vm/os_bsd.cpp Changeset: c40fbf634c90 Author: morris Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c40fbf634c90 8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp Summary: fix null pointer Reviewed-by: kvn ! src/share/vm/runtime/frame.cpp Changeset: 571076d3c79d Author: shade Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/571076d3c79d 8009120: Fuzz instruction scheduling in HotSpot compilers Reviewed-by: kvn, vlivanov ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 4f553e24b3b5 Author: vlivanov Date: 2013-03-05 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4f553e24b3b5 Merge Changeset: 872b3feace55 Author: morris Date: 2013-03-05 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/872b3feace55 8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp Summary: fix null pointer Reviewed-by: kvn, coleenp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 8651f608fea4 Author: roland Date: 2013-03-06 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8651f608fea4 8009460: C2compiler crash in machnode::in_regmask(unsigned int) Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: ff55877839bc Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff55877839bc 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: bdb602473679 Author: morris Date: 2013-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bdb602473679 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: b5bd25d55994 Author: morris Date: 2013-03-07 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5bd25d55994 Merge From konstantin.shefov at oracle.com Mon Mar 11 13:07:20 2013 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 12 Mar 2013 00:07:20 +0400 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E3632.20502@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> Message-ID: <513E3978.2000109@oracle.com> All these tests compile and run under all OSs, not MacOS only. There are a lot of awt and swing tests that depend on test.java.awt.regtesthelpers, they are in the openjdk repo. Almost none of regression tests are ever run without JTREG. Konstantin 11.03.2013 23:53, Phil Race ?????: > Konstantin, > > First I am puzzled by the decision to send this to AWT and Swing lists. > There are a couple of Swing tests and a large number of AWT tests > but it seems to be also a very large number of 2D/graphics tests PLUS > a large scattering in other areas such as > - hotspot/managment > - jndi > - java.io > - java.nio > - threading > - reflection > - networking. > > Next, I am surprised to see jtreg tests that depend on junit. > > I just searched our entire regression test suite (including ones that > are still closed for various reasons) and I didn't find *any* client area > tests that have this dependency. > > All I found are a few core java reflection tests. > Nor should these tests depend on the harness in "package test.java.awt" > > So they should all be standalone tests that can be run without any > harness. > > On top of that I seriously doubt that these all even *compile* on > anything > besides OS X, and may not pass elsewhere either > > cf : 31 import com.apple.eio.FileManager; > As it is none of this appears appropriate to put into the test directory. > > So this > 1) First needs to be rid of harness dependencies > 2) Needs to be made to compile on all platforms or invoked by a script > which builds only on OS X > 3) All tests that build on all platforms must pass on all platforms > 4) The review needs to be send to all affected lists - which is pretty > much all of them! > awt, 2d, swing, hotspot, core-libs .. maybe more > > -phil. > > > > On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >> Please, review the fix. >> >> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>> >>> Changed tags to @run junit >>> >>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>> A few options exists: >>>> 1 Changes tag to @run junit + jtreg 4.1 >>>> 2 Remove usage of junit from these tests. >>>> >>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>> >>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>> I have already ran those tests on Windows before sending this >>>>>>>> request, all is OK 95% pass. >>>>>>>> >>>>>>>> I should also note that we (STT regression team) use JTREG 3.2 >>>>>>>> for testing with option >>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere. >>>>>> But if it is standard to use @run junit tag, we will replace >>>>>> jtreg we use to version 4.1. >>>>> >>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>> Swing tests on Unix systems. >>>>> >>>>> I would suggest to use the JTreg 4.1. The standard is to use >>>>> the @run junit tag for the JTReg 4.1 (in other case the junit lib >>>>> is not put to the test JDK classpath). >>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>> directory because of the licensing reasons: >>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. So >>>>>>>> I suggest NOT to replace @run main to @run juint, and, istead >>>>>>>> of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>> >>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>> Hi, Konstantin. >>>>>>>>> I think yes. Please try to run these tests on windows as well. >>>>>>>>> At least they should be compiled. >>>>>>>>> >>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, >>>>>>>>>> one gets compilation errors. So should I replace @run main to >>>>>>>>>> @run juint in all 150 tests? >>>>>>>>>> >>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>> >>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and made >>>>>>>>>>>>> swing mwthod to run on EDT. >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>> - Is it possible to run the test with jtreg or JUnit >>>>>>>>>>>>>> is necessary for the test invocation? >>>>>>>>>>>> >>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>> does not exist. >>>>>>>>>>>> It seems it is because the '@run main TestDoublePaint' >>>>>>>>>>>> jtreg task does not put the junit jar to the test jdk class >>>>>>>>>>>> path. >>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the test. >>>>>>>>>>>> (I use the JTReg 4.1 b05 from >>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>> It is also interesting is it necessary to have the main >>>>>>>>>>>> method for the junit task? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds should >>>>>>>>>>>>>> be plenty enough to catch 2 repaints >>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() method >>>>>>>>>>>>>> here? >>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From philip.race at oracle.com Mon Mar 11 13:22:29 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Mar 2013 13:22:29 -0700 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E3978.2000109@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> Message-ID: <513E3D05.8080209@oracle.com> On 3/11/2013 1:07 PM, Konstantin Shefov wrote: > All these tests compile and run under all OSs, not MacOS only. I find that very difficult to believe. \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac APIPresent.java APIPresent.java:31: error: package com.apple.eio does not exist import com.apple.eio.FileManager; > There are a lot of awt and swing tests that depend on > test.java.awt.regtesthelpers, they are in the openjdk repo. This is true although that is news to me, I presume this is guaranteed to be compiled automatically when you compile the main test. > Almost none of regression tests are ever run without JTREG. That's not true. I've been running and writing reg. tests for 12 years and I use jtreg less than 0.01% of the time .. as in I can't remember last time I needed to use it. That's the biggest plus we have here. You don't *need* a big horrible useless harness that obscures the real test. I object strongly to junit dependencies in any of the tests. -phil. > > Konstantin > > 11.03.2013 23:53, Phil Race ?????: >> Konstantin, >> >> First I am puzzled by the decision to send this to AWT and Swing lists. >> There are a couple of Swing tests and a large number of AWT tests >> but it seems to be also a very large number of 2D/graphics tests PLUS >> a large scattering in other areas such as >> - hotspot/managment >> - jndi >> - java.io >> - java.nio >> - threading >> - reflection >> - networking. >> >> Next, I am surprised to see jtreg tests that depend on junit. >> >> I just searched our entire regression test suite (including ones that >> are still closed for various reasons) and I didn't find *any* client >> area >> tests that have this dependency. >> >> All I found are a few core java reflection tests. >> Nor should these tests depend on the harness in "package test.java.awt" >> >> So they should all be standalone tests that can be run without any >> harness. >> >> On top of that I seriously doubt that these all even *compile* on >> anything >> besides OS X, and may not pass elsewhere either >> >> cf : 31 import com.apple.eio.FileManager; >> As it is none of this appears appropriate to put into the test >> directory. >> >> So this >> 1) First needs to be rid of harness dependencies >> 2) Needs to be made to compile on all platforms or invoked by a script >> which builds only on OS X >> 3) All tests that build on all platforms must pass on all platforms >> 4) The review needs to be send to all affected lists - which is >> pretty much all of them! >> awt, 2d, swing, hotspot, core-libs .. maybe more >> >> -phil. >> >> >> >> On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >>> Please, review the fix. >>> >>> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>>> >>>> Changed tags to @run junit >>>> >>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>>> A few options exists: >>>>> 1 Changes tag to @run junit + jtreg 4.1 >>>>> 2 Remove usage of junit from these tests. >>>>> >>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>>> >>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>>> I have already ran those tests on Windows before sending this >>>>>>>>> request, all is OK 95% pass. >>>>>>>>> >>>>>>>>> I should also note that we (STT regression team) use JTREG 3.2 >>>>>>>>> for testing with option >>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere. >>>>>>> But if it is standard to use @run junit tag, we will replace >>>>>>> jtreg we use to version 4.1. >>>>>> >>>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>>> Swing tests on Unix systems. >>>>>> >>>>>> I would suggest to use the JTreg 4.1. The standard is to use >>>>>> the @run junit tag for the JTReg 4.1 (in other case the junit lib >>>>>> is not put to the test JDK classpath). >>>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>>> directory because of the licensing reasons: >>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. So >>>>>>>>> I suggest NOT to replace @run main to @run juint, and, istead >>>>>>>>> of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>>> >>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Konstantin. >>>>>>>>>> I think yes. Please try to run these tests on windows as >>>>>>>>>> well. At least they should be compiled. >>>>>>>>>> >>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, >>>>>>>>>>> one gets compilation errors. So should I replace @run main >>>>>>>>>>> to @run juint in all 150 tests? >>>>>>>>>>> >>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>>> >>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and >>>>>>>>>>>>>> made swing mwthod to run on EDT. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Is it possible to run the test with jtreg or JUnit >>>>>>>>>>>>>>> is necessary for the test invocation? >>>>>>>>>>>>> >>>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>>> does not exist. >>>>>>>>>>>>> It seems it is because the '@run main TestDoublePaint' >>>>>>>>>>>>> jtreg task does not put the junit jar to the test jdk >>>>>>>>>>>>> class path. >>>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the test. >>>>>>>>>>>>> (I use the JTReg 4.1 b05 from >>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>>> It is also interesting is it necessary to have the >>>>>>>>>>>>> main method for the junit task? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds should >>>>>>>>>>>>>>> be plenty enough to catch 2 repaints >>>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() >>>>>>>>>>>>>>> method here? >>>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From konstantin.shefov at oracle.com Mon Mar 11 13:45:14 2013 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 12 Mar 2013 00:45:14 +0400 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E3D05.8080209@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> <513E3D05.8080209@oracle.com> Message-ID: <513E425A.4030504@oracle.com> Phil, 12.03.2013 0:22, Phil Race wrote: > On 3/11/2013 1:07 PM, Konstantin Shefov wrote: >> All these tests compile and run under all OSs, not MacOS only. > > I find that very difficult to believe. > > \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac APIPresent.java > APIPresent.java:31: error: package com.apple.eio does not exist > import com.apple.eio.FileManager; > Yes, there are actually 6 tests with com.apple.* packages, but the total number is about 150, I can send you a pass log on windows and linux later. >> There are a lot of awt and swing tests that depend on >> test.java.awt.regtesthelpers, they are in the openjdk repo. > > This is true although that is news to me, I presume this is guaranteed to > be compiled automatically when you compile the main test. > No main test exists, JTREG tags like "@library DIRECTORY_PATH" "@build CLASS_NAME" make this test.java.awt.regtesthelpers stuff to compile for every single test. >> Almost none of regression tests are ever run without JTREG. > > That's not true. I've been running and writing reg. tests for 12 years > and I use jtreg less than 0.01% of the time .. as in I can't remember > last time I needed to use it. That's the biggest plus we have here. > You don't *need* a big horrible useless harness that obscures > the real test. I object strongly to junit dependencies in any of the > tests. SQE teams run automated tests using JTREG rather often (if not always). Even manual tests are run with JTREG. So do you suggest to remove junit from all these tests? All these tests depend on junit. -Konstantin > > -phil. > >> >> Konstantin >> >> 11.03.2013 23:53, Phil Race wrote: >>> Konstantin, >>> >>> First I am puzzled by the decision to send this to AWT and Swing lists. >>> There are a couple of Swing tests and a large number of AWT tests >>> but it seems to be also a very large number of 2D/graphics tests PLUS >>> a large scattering in other areas such as >>> - hotspot/managment >>> - jndi >>> - java.io >>> - java.nio >>> - threading >>> - reflection >>> - networking. >>> >>> Next, I am surprised to see jtreg tests that depend on junit. >>> >>> I just searched our entire regression test suite (including ones that >>> are still closed for various reasons) and I didn't find *any* client >>> area >>> tests that have this dependency. >>> >>> All I found are a few core java reflection tests. >>> Nor should these tests depend on the harness in "package test.java.awt" >>> >>> So they should all be standalone tests that can be run without any >>> harness. >>> >>> On top of that I seriously doubt that these all even *compile* on >>> anything >>> besides OS X, and may not pass elsewhere either >>> >>> cf : 31 import com.apple.eio.FileManager; >>> As it is none of this appears appropriate to put into the test >>> directory. >>> >>> So this >>> 1) First needs to be rid of harness dependencies >>> 2) Needs to be made to compile on all platforms or invoked by a script >>> which builds only on OS X >>> 3) All tests that build on all platforms must pass on all platforms >>> 4) The review needs to be send to all affected lists - which is >>> pretty much all of them! >>> awt, 2d, swing, hotspot, core-libs .. maybe more >>> >>> -phil. >>> >>> >>> >>> On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >>>> Please, review the fix. >>>> >>>> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>>>> >>>>> Changed tags to @run junit >>>>> >>>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>>>> A few options exists: >>>>>> 1 Changes tag to @run junit + jtreg 4.1 >>>>>> 2 Remove usage of junit from these tests. >>>>>> >>>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>>>> >>>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>>>> I have already ran those tests on Windows before sending this >>>>>>>>>> request, all is OK 95% pass. >>>>>>>>>> >>>>>>>>>> I should also note that we (STT regression team) use JTREG >>>>>>>>>> 3.2 for testing with option >>>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>>>> There is no junit.jar in JTREG 3, but it could be taken elsewhere. >>>>>>>> But if it is standard to use @run junit tag, we will replace >>>>>>>> jtreg we use to version 4.1. >>>>>>> >>>>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>>>> Swing tests on Unix systems. >>>>>>> >>>>>>> I would suggest to use the JTreg 4.1. The standard is to use >>>>>>> the @run junit tag for the JTReg 4.1 (in other case the junit >>>>>>> lib is not put to the test JDK classpath). >>>>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>>>> directory because of the licensing reasons: >>>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. >>>>>>>>>> So I suggest NOT to replace @run main to @run juint, and, >>>>>>>>>> istead of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>>>> >>>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>>>> Hi, Konstantin. >>>>>>>>>>> I think yes. Please try to run these tests on windows as >>>>>>>>>>> well. At least they should be compiled. >>>>>>>>>>> >>>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses b05, >>>>>>>>>>>> one gets compilation errors. So should I replace @run main >>>>>>>>>>>> to @run juint in all 150 tests? >>>>>>>>>>>> >>>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>>>> >>>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and >>>>>>>>>>>>>>> made swing mwthod to run on EDT. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Is it possible to run the test with jtreg or >>>>>>>>>>>>>>>> JUnit is necessary for the test invocation? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>>>> does not exist. >>>>>>>>>>>>>> It seems it is because the '@run main >>>>>>>>>>>>>> TestDoublePaint' jtreg task does not put the junit jar to >>>>>>>>>>>>>> the test jdk class path. >>>>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the >>>>>>>>>>>>>> test. (I use the JTReg 4.1 b05 from >>>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>>>> It is also interesting is it necessary to have the >>>>>>>>>>>>>> main method for the junit task? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds should >>>>>>>>>>>>>>>> be plenty enough to catch 2 repaints >>>>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() >>>>>>>>>>>>>>>> method here? >>>>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From philip.race at oracle.com Mon Mar 11 13:53:44 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Mar 2013 13:53:44 -0700 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E425A.4030504@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> <513E3D05.8080209@oracle.com> <513E425A.4030504@oracle.com> Message-ID: <513E4458.7090500@oracle.com> Konstantin, On 3/11/2013 1:45 PM, Konstantin Shefov wrote: > Phil, > > 12.03.2013 0:22, Phil Race wrote: >> On 3/11/2013 1:07 PM, Konstantin Shefov wrote: >>> All these tests compile and run under all OSs, not MacOS only. >> >> I find that very difficult to believe. >> >> \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac >> APIPresent.java >> APIPresent.java:31: error: package com.apple.eio does not exist >> import com.apple.eio.FileManager; >> > > Yes, there are actually 6 tests with com.apple.* packages, but the > total number is about 150, I can send you a pass log on windows and > linux later. > >>> There are a lot of awt and swing tests that depend on >>> test.java.awt.regtesthelpers, they are in the openjdk repo. >> >> This is true although that is news to me, I presume this is >> guaranteed to >> be compiled automatically when you compile the main test. >> > > No main test exists, JTREG tags like "@library DIRECTORY_PATH" "@build > CLASS_NAME" make this test.java.awt.regtesthelpers stuff to compile > for every single test. ' By main test, I mean whatever jtreg test imports these classes/packages. > >>> Almost none of regression tests are ever run without JTREG. >> >> That's not true. I've been running and writing reg. tests for 12 years >> and I use jtreg less than 0.01% of the time .. as in I can't remember >> last time I needed to use it. That's the biggest plus we have here. >> You don't *need* a big horrible useless harness that obscures >> the real test. I object strongly to junit dependencies in any of the >> tests. > > SQE teams run automated tests using JTREG rather often (if not > always). Even manual tests are run with JTREG. Right, its just not true that everyone works the same way. > > So do you suggest to remove junit from all these tests? All these > tests depend on junit. That is what I am suggesting. -phil. > > -Konstantin > >> >> -phil. >> >>> >>> Konstantin >>> >>> 11.03.2013 23:53, Phil Race wrote: >>>> Konstantin, >>>> >>>> First I am puzzled by the decision to send this to AWT and Swing >>>> lists. >>>> There are a couple of Swing tests and a large number of AWT tests >>>> but it seems to be also a very large number of 2D/graphics tests PLUS >>>> a large scattering in other areas such as >>>> - hotspot/managment >>>> - jndi >>>> - java.io >>>> - java.nio >>>> - threading >>>> - reflection >>>> - networking. >>>> >>>> Next, I am surprised to see jtreg tests that depend on junit. >>>> >>>> I just searched our entire regression test suite (including ones that >>>> are still closed for various reasons) and I didn't find *any* >>>> client area >>>> tests that have this dependency. >>>> >>>> All I found are a few core java reflection tests. >>>> Nor should these tests depend on the harness in "package >>>> test.java.awt" >>>> >>>> So they should all be standalone tests that can be run without any >>>> harness. >>>> >>>> On top of that I seriously doubt that these all even *compile* on >>>> anything >>>> besides OS X, and may not pass elsewhere either >>>> >>>> cf : 31 import com.apple.eio.FileManager; >>>> As it is none of this appears appropriate to put into the test >>>> directory. >>>> >>>> So this >>>> 1) First needs to be rid of harness dependencies >>>> 2) Needs to be made to compile on all platforms or invoked by a script >>>> which builds only on OS X >>>> 3) All tests that build on all platforms must pass on all platforms >>>> 4) The review needs to be send to all affected lists - which is >>>> pretty much all of them! >>>> awt, 2d, swing, hotspot, core-libs .. maybe more >>>> >>>> -phil. >>>> >>>> >>>> >>>> On 3/11/2013 2:03 AM, Konstantin Shefov wrote: >>>>> Please, review the fix. >>>>> >>>>> On 06-Mar-13 15:14, Konstantin Shefov wrote: >>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.02/ >>>>>> >>>>>> Changed tags to @run junit >>>>>> >>>>>> On 04-Mar-13 14:44, Sergey Bylokhov wrote: >>>>>>> A few options exists: >>>>>>> 1 Changes tag to @run junit + jtreg 4.1 >>>>>>> 2 Remove usage of junit from these tests. >>>>>>> >>>>>>> 01.03.2013 14:26, Alexander Scherbatiy ?????: >>>>>>>> On 3/1/2013 1:29 PM, Konstantin Shefov wrote: >>>>>>>>> >>>>>>>>> On 01-Mar-13 13:24, Sergey Bylokhov wrote: >>>>>>>>>> 01.03.2013 12:24, Konstantin Shefov wrote: >>>>>>>>>>> I have already ran those tests on Windows before sending >>>>>>>>>>> this request, all is OK 95% pass. >>>>>>>>>>> >>>>>>>>>>> I should also note that we (STT regression team) use JTREG >>>>>>>>>>> 3.2 for testing with option >>>>>>>>>>> -cpa:$JEMMY_PATH/jemmy.jar,$JUNIT_PATH/junit.jar >>>>>>>>>> As far as I understand, jtreg 3 doesn't contain junit.jar. >>>>>>>>> There is no junit.jar in JTREG 3, but it could be taken >>>>>>>>> elsewhere. >>>>>>>>> But if it is standard to use @run junit tag, we will replace >>>>>>>>> jtreg we use to version 4.1. >>>>>>>> >>>>>>>> The jtreg 3 does not have fix for the issue "7113599 jtreg >>>>>>>> should handle GNOME_DESKTOP_SESSION_ID" which affects some L&F >>>>>>>> Swing tests on Unix systems. >>>>>>>> >>>>>>>> I would suggest to use the JTreg 4.1. The standard is to >>>>>>>> use the @run junit tag for the JTReg 4.1 (in other case the >>>>>>>> junit lib is not put to the test JDK classpath). >>>>>>>> The junit.jar has been removed from the JTReg 4.1 lib >>>>>>>> directory because of the licensing reasons: >>>>>>>> https://blogs.oracle.com/jjg/entry/jtreg_update1 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>>>> JTREG 3.2 is more stable than 4.1. We do not use JTREG 4.1. >>>>>>>>>>> So I suggest NOT to replace @run main to @run juint, and, >>>>>>>>>>> istead of that add jtreg option -cpa:$JUNIT_PATH/junit.jar >>>>>>>>>>> >>>>>>>>>>> On 28-Feb-13 18:35, Sergey Bylokhov wrote: >>>>>>>>>>>> Hi, Konstantin. >>>>>>>>>>>> I think yes. Please try to run these tests on windows as >>>>>>>>>>>> well. At least they should be compiled. >>>>>>>>>>>> >>>>>>>>>>>> 28.02.2013 17:55, Konstantin Shefov wrote: >>>>>>>>>>>>> I used JTREG 4.1 fcs b03, not b05. Indeed, if one uses >>>>>>>>>>>>> b05, one gets compilation errors. So should I replace @run >>>>>>>>>>>>> main to @run juint in all 150 tests? >>>>>>>>>>>>> >>>>>>>>>>>>> On 28-Feb-13 17:46, Konstantin Shefov wrote: >>>>>>>>>>>>>> Strange, but I used JTReg 4.1 b05 also and I had no >>>>>>>>>>>>>> compilation errors. JUnit is automatically added in the >>>>>>>>>>>>>> latest JTREG 4.1. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28-Feb-13 17:02, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 2/27/2013 5:45 PM, Konstantin Shefov wrote: >>>>>>>>>>>>>>>> I replaced Thread.sleep() with toolkit.realSync() and >>>>>>>>>>>>>>>> made swing mwthod to run on EDT. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> New webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/7145406/webrev.01 >>>>>>>>>>>>>>>>> test/javax/swing/JComponent/DoublePaint/TestDoublePaint.java >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Is it possible to run the test with jtreg or >>>>>>>>>>>>>>>>> JUnit is necessary for the test invocation? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I run the test and got the compilation error: >>>>>>>>>>>>>>> TestDoublePaint.java:34: error: package junit.framework >>>>>>>>>>>>>>> does not exist. >>>>>>>>>>>>>>> It seems it is because the '@run main >>>>>>>>>>>>>>> TestDoublePaint' jtreg task does not put the junit jar >>>>>>>>>>>>>>> to the test jdk class path. >>>>>>>>>>>>>>> The '@run junit TestDoublePaint' task passes the >>>>>>>>>>>>>>> test. (I use the JTReg 4.1 b05 from >>>>>>>>>>>>>>> http://download.java.net/openjdk/jtreg/) >>>>>>>>>>>>>>> It is also interesting is it necessary to have the >>>>>>>>>>>>>>> main method for the junit task? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - line: 68 Thread.sleep(2000); // 2 seconds >>>>>>>>>>>>>>>>> should be plenty enough to catch 2 repaints >>>>>>>>>>>>>>>>> Is it possible to use the toolkit.realSync() >>>>>>>>>>>>>>>>> method here? >>>>>>>>>>>>>>>>> - Swing classes should be created and used on the EDT. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Mon Mar 11 14:48:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2013 21:48:56 +0000 Subject: [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <513E4458.7090500@oracle.com> References: <512B3412.1090500@oracle.com> <512B7ED2.8040608@oracle.com> <512E0E16.4060708@oracle.com> <512F5553.5030105@oracle.com> <512F5FBB.7030203@oracle.com> <512F61EA.9080102@oracle.com> <512F6B44.3080808@oracle.com> <513065BB.5070707@oracle.com> <513073D7.9030108@oracle.com> <513074FA.2040804@oracle.com> <51308269.5070500@oracle.com> <51347B0B.4040709@oracle.com> <5137251A.4000607@oracle.com> <513D9DDE.3010600@oracle.com> <513E3632.20502@oracle.com> <513E3978.2000109@oracle.com> <513E3D05.8080209@oracle.com> <513E425A.4030504@oracle.com> <513E4458.7090500@oracle.com> Message-ID: <513E5148.7040105@oracle.com> Konstantin, Can you hold off pushing these tests until there has been wider review? I may be mistaken but I think that many of these tests (at least for the non-client areas) were deliberately not pushed to jdk7u and jdk8 when bringing the port in. From what I can remember there was overlap with existing tests, tests weren't organized consistently with the existing tests, some tests used hard-coded ports in a number of cases and there were a slew of other issues that would have required clean-up and work to get them to run reliably on all platforms. Additional tests are of course very welcome and maybe there has been work done to clean them and get them reliable, but we need to be sure that we aren't been sold a pup. -Alan From bob.vandette at oracle.com Mon Mar 18 14:27:03 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 18 Mar 2013 17:27:03 -0400 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <514783DD.1050206@oracle.com> References: <5142BDDF.9040907@oracle.com> <514783DD.1050206@oracle.com> Message-ID: <229C6CEB-75E7-4EB3-8939-7F59D0266443@oracle.com> Why is this entry "${jprt.my.linux.armvh}-{product|fastdebug}" and not ${jprt.my.linux.armvfphflt}-{product|fastdebug} Why can't you treat embedded and non embedded architecture names the same and just append Emb for embedded specific targets? Bob. On Mar 18, 2013, at 5:15 PM, David Holmes wrote: > Need a Reviewer please. > > David > > On 15/03/2013 4:21 PM, David Holmes wrote: >> The CR for this is not public. These are just some renamings of our JPRT >> build targets. >> >> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >> >> This will be pushed via hotspot-emb once some internal changes are in >> place to deal with the new names. >> >> I will need a hotspot Reviewer for this please. (You know who you are! ;-)) >> >> Thanks, >> David From jesper.wilhelmsson at oracle.com Mon Mar 18 14:29:32 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 18 Mar 2013 22:29:32 +0100 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <51478453.9040202@oracle.com> References: <5142BDDF.9040907@oracle.com> <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> <51478453.9040202@oracle.com> Message-ID: <5147873C.7050704@oracle.com> David, Your comment in line 106 says that "The ARM GP vfp-sflt build is not currently supported" and in the following lines you comment out armvs, while in the lines above armvfpsflt is included as a build target. Is this correct? /Jesper On 18/3/13 10:17 PM, David Holmes wrote: > Thanks Chris. > > Please ignore my previous email seeking a Reviewer. I hadn't realized you were a > Reviewer. > > Still need a second reviewer though. > > David > > On 16/03/2013 3:12 AM, Christian Thalinger wrote: >> Looks good to me. -- Chris >> >> On Mar 14, 2013, at 11:21 PM, David Holmes wrote: >> >>> The CR for this is not public. These are just some renamings of our JPRT >>> build targets. >>> >>> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >>> >>> This will be pushed via hotspot-emb once some internal changes are in place >>> to deal with the new names. >>> >>> I will need a hotspot Reviewer for this please. (You know who you are! ;-)) >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Mon Mar 18 14:33:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 07:33:36 +1000 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <5147873C.7050704@oracle.com> References: <5142BDDF.9040907@oracle.com> <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> <51478453.9040202@oracle.com> <5147873C.7050704@oracle.com> Message-ID: <51478830.6050607@oracle.com> On 19/03/2013 7:29 AM, Jesper Wilhelmsson wrote: > David, > > Your comment in line 106 says that "The ARM GP vfp-sflt build is not > currently supported" and in the following lines you comment out armvs, > while in the lines above armvfpsflt is included as a build target. Is > this correct? Yes. armvfpsflt is an embedded platform. armvs is the SE platform for the same "vfp-sflt" architecture. Thanks, David > /Jesper > > > On 18/3/13 10:17 PM, David Holmes wrote: >> Thanks Chris. >> >> Please ignore my previous email seeking a Reviewer. I hadn't realized >> you were a >> Reviewer. >> >> Still need a second reviewer though. >> >> David >> >> On 16/03/2013 3:12 AM, Christian Thalinger wrote: >>> Looks good to me. -- Chris >>> >>> On Mar 14, 2013, at 11:21 PM, David Holmes >>> wrote: >>> >>>> The CR for this is not public. These are just some renamings of our >>>> JPRT >>>> build targets. >>>> >>>> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >>>> >>>> This will be pushed via hotspot-emb once some internal changes are >>>> in place >>>> to deal with the new names. >>>> >>>> I will need a hotspot Reviewer for this please. (You know who you >>>> are! ;-)) >>>> >>>> Thanks, >>>> David >>> From david.holmes at oracle.com Mon Mar 18 14:35:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 07:35:15 +1000 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <229C6CEB-75E7-4EB3-8939-7F59D0266443@oracle.com> References: <5142BDDF.9040907@oracle.com> <514783DD.1050206@oracle.com> <229C6CEB-75E7-4EB3-8939-7F59D0266443@oracle.com> Message-ID: <51478893.4000309@oracle.com> On 19/03/2013 7:27 AM, Bob Vandette wrote: > Why is this entry "${jprt.my.linux.armvh}-{product|fastdebug}" > > and not > > ${jprt.my.linux.armvfphflt}-{product|fastdebug} > > > Why can't you treat embedded and non embedded architecture names the > same and just append Emb for embedded specific targets? Because that is not the way JPRT handles them. I don't know if they can be the way you suggest, but as it stands there are distinct platform designators for SE builds versus Embedded builds within JPRT. David > > > Bob. > > > > On Mar 18, 2013, at 5:15 PM, David Holmes wrote: > >> Need a Reviewer please. >> >> David >> >> On 15/03/2013 4:21 PM, David Holmes wrote: >>> The CR for this is not public. These are just some renamings of our JPRT >>> build targets. >>> >>> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >>> >>> This will be pushed via hotspot-emb once some internal changes are in >>> place to deal with the new names. >>> >>> I will need a hotspot Reviewer for this please. (You know who you >>> are! ;-)) >>> >>> Thanks, >>> David > From zhengyu.gu at oracle.com Mon Mar 18 15:52:59 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Mon, 18 Mar 2013 22:52:59 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130318225306.4B72D4822A@hg.openjdk.java.net> Changeset: 76451677d919 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/76451677d919 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 893fd4dc2d3b Author: zgu Date: 2013-03-18 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/893fd4dc2d3b Merge From goetz.lindenmaier at sap.com Tue Mar 19 02:21:01 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Mar 2013 09:21:01 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <51475515.9050908@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <50D26B81.8080903@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> <51475515.9050908@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> Hi John, Good to see there is work on this! We'll be happy to test your change, but we are pretty sure it will fail if you don't issue an isync instruction. To properly compare our and your implementation we need to know how you implemented OrderAccess, i.e., file orderAccess_linux_ppc.inline.hpp. If you may not share this file from your closed source, could you please compare it yourself to our implementation? Ours is open ;) http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/39fdd72ec591/src/os_cpu/linux_ppc/vm/ > BTW - whatever patch is committed - I intend to make you the contributor. That's nice, but please account this fix to Axel Siebenborn, he analyzed the bug, dug out the paper and did the fix. I only do the openJDK contribution. Anyways, I'm off next week, so he will take over. Best regards, Goetz. -----Original Message----- From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Montag, 18. M?rz 2013 18:56 To: Lindenmaier, Goetz Cc: Vitaly Davidovich; David Chase; Simonis, Volker; David Holmes; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): Memory ordering in taskqueue.hpp Hi Geotz, I have a patch that I synthesized from yours that I gave to one our engineers who is working on PowerPC. He was seeing crashes before applying your patch and mine. With either patch applied, the crashes disappear. The only real difference between our patches is that I only ordered access to the _bottom field and left accesses to the _age field (and it's sub fields) unordered. If I give you my patch do you think you could test with it? It might take a day or two as I want to get the fixes for the G1 marking bugs committed - the stability of G1 is my highest priority. BTW - whatever patch is committed - I intend to make you the contributor. Cheers, JohnC On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: > Hi, > > I want to take up this issue again. > I think we gave a good reason for the fence we added in the taskqueue. > Do you have any remaining objections against this change? We are > happy to discuss or adapt the change. > If not, could somebody please push this change to hotspot? > > http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ > > Best regards, > Goetz. > > > From: Vitaly Davidovich [mailto:vitalyd at gmail.com] > Sent: Freitag, 8. M?rz 2013 17:13 > To: Volker Simonis > Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > > I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). > > Sent from my phone > On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz > > wrote: >> Hi Vitaly, >> >> the writer has a sync after the write to bottom (see pop_local) >> but the store and the sync are not one atomic operation. Stuff >> can happen before the sync is executed. Therefore the reader >> must sync, too. >> > Exactly - you have three threads. The first one executes the write > to bottom but not the following sync. The second thread reads this > new value (by chance) and uses it but the third thread still sees the > old value because there's no multipl-copy-atomicity on PPC. So we > really need the sync before the read to assure thread three is not seeing > an older value than thread two. > >> Anyways, in pop_global it should be cheaper than in pop_local. >> >> Best regards, >> Geotz. >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 16:13 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >> Hi Vitaly, >> >> No, the problem is not reordering. The problem is that >> _bottom, which is read after _age, might be older than _age because >> another processor didn't write it back yet. The fence (sync) makes the >> current thread wait until it has the new _bottom. >> On Power, a write is not visible to all other threads simultaneously >> (no multipl-copy-atomicity). >> >> What you propose helps if you look at two processors, but not if >> four threads on four processors are involved. >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >> Sent: Freitag, 8. M?rz 2013 15:29 >> To: Lindenmaier, Goetz >> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >> >> >> Hi Goetz, >> >> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >> >> Thanks >> >> Sent from my phone >> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >> Hi, >> >> we have been, and still are, doing research on this issue. >> We want to keep you up to date on this, and propose on the >> further proceeding. >> >> You asked explicit memory ordering operations and a rationale >> why we added them. >> >> Axel found a paper describing the task queue algorithm and the >> needed ordering on arm and power: >> Correct and Efficient Work-Stealing for Weak Memory Models; >> L?, Pop, Cohen, Nardelli; PPoPP'13; >> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >> >> According to this paper we need to add one fence and one load_acquire >> to your implementation of the task queue. You find this fence in this small >> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> With this fence, the algorithm works on Linux for our openjdk ppc >> port, and also for our SAP JVM . >> >> Actually, the fence fixes a problem we discovered with the concurrency >> torture test suite. The problem occurs with four or more GC threads. >> If three threads are stealing from the queue of the fourth, two of >> them can pop the same element. Without a fence between the access >> to age and bottom in pop_global(), bottom can be older than age. >> >> >> Unfortunately, the OpenJDK implementation with the added fence >> does not work on AIX. Axel already detected one place where the xlC >> compiler optimization removed load instruction that is required for >> the correctness of the algorithm. If we use our access routines with load_acquire >> (see original webrev below) everything works, unclear why. >> >> Now, we think C++ might allow that this load is removed and xlC does >> the correct, but unexpected thing. On the other hand it might also be >> a compiler bug. >> We are currently discussing this with the IBM xlC developers. >> >> Best regards, >> Axel and Goetz. >> >> >> PS: The webrev we proposed originally: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >> >> >> >> >> >> From david.holmes at oracle.com Tue Mar 19 02:37:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 19:37:25 +1000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> <51475515.9050908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> Message-ID: <514831D5.9000901@oracle.com> Hi Goetz, On 19/03/2013 7:21 PM, Lindenmaier, Goetz wrote: > Hi John, > > Good to see there is work on this! > We'll be happy to test your change, but we are pretty sure it will fail > if you don't issue an isync instruction. > To properly compare our and your implementation we need to > know how you implemented OrderAccess, i.e., file > orderAccess_linux_ppc.inline.hpp. > > If you may not share this file from your closed source, > could you please compare it yourself to our implementation? > Ours is open ;) > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/39fdd72ec591/src/os_cpu/linux_ppc/vm/ Looking at the JMM cookbook: http://g.oswego.edu/dl/jmm/cookbook.html and your implementation, I note that you use explicit fences (lwsync) for loadStore and loadLoad, where it is also possible to introduce a dependent-load+isync to get the same effect. David ----- >> BTW - whatever patch is committed - I intend to make you the contributor. > That's nice, but please account this fix to Axel Siebenborn, he analyzed the bug, > dug out the paper and did the fix. I only do the openJDK contribution. > Anyways, I'm off next week, so he will take over. > > Best regards, > Goetz. > > > > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Montag, 18. M?rz 2013 18:56 > To: Lindenmaier, Goetz > Cc: Vitaly Davidovich; David Chase; Simonis, Volker; David Holmes; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > Hi Geotz, > > I have a patch that I synthesized from yours that I gave to one our > engineers who is working on PowerPC. He was seeing crashes before > applying your patch and mine. With either patch applied, the crashes > disappear. > > The only real difference between our patches is that I only ordered > access to the _bottom field and left accesses to the _age field (and > it's sub fields) unordered. If I give you my patch do you think you > could test with it? It might take a day or two as I want to get the > fixes for the G1 marking bugs committed - the stability of G1 is my > highest priority. > > BTW - whatever patch is committed - I intend to make you the contributor. > > Cheers, > > JohnC > > On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I want to take up this issue again. >> I think we gave a good reason for the fence we added in the taskqueue. >> Do you have any remaining objections against this change? We are >> happy to discuss or adapt the change. >> If not, could somebody please push this change to hotspot? >> >> http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 17:13 >> To: Volker Simonis >> Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >> >> >> I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). >> >> Sent from my phone >> On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: >> On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz >> > wrote: >>> Hi Vitaly, >>> >>> the writer has a sync after the write to bottom (see pop_local) >>> but the store and the sync are not one atomic operation. Stuff >>> can happen before the sync is executed. Therefore the reader >>> must sync, too. >>> >> Exactly - you have three threads. The first one executes the write >> to bottom but not the following sync. The second thread reads this >> new value (by chance) and uses it but the third thread still sees the >> old value because there's no multipl-copy-atomicity on PPC. So we >> really need the sync before the read to assure thread three is not seeing >> an older value than thread two. >> >>> Anyways, in pop_global it should be cheaper than in pop_local. >>> >>> Best regards, >>> Geotz. >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 16:13 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >>> Hi Vitaly, >>> >>> No, the problem is not reordering. The problem is that >>> _bottom, which is read after _age, might be older than _age because >>> another processor didn't write it back yet. The fence (sync) makes the >>> current thread wait until it has the new _bottom. >>> On Power, a write is not visible to all other threads simultaneously >>> (no multipl-copy-atomicity). >>> >>> What you propose helps if you look at two processors, but not if >>> four threads on four processors are involved. >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >>> Sent: Freitag, 8. M?rz 2013 15:29 >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hi Goetz, >>> >>> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >>> Hi, >>> >>> we have been, and still are, doing research on this issue. >>> We want to keep you up to date on this, and propose on the >>> further proceeding. >>> >>> You asked explicit memory ordering operations and a rationale >>> why we added them. >>> >>> Axel found a paper describing the task queue algorithm and the >>> needed ordering on arm and power: >>> Correct and Efficient Work-Stealing for Weak Memory Models; >>> L?, Pop, Cohen, Nardelli; PPoPP'13; >>> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >>> >>> According to this paper we need to add one fence and one load_acquire >>> to your implementation of the task queue. You find this fence in this small >>> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>> >>> With this fence, the algorithm works on Linux for our openjdk ppc >>> port, and also for our SAP JVM . >>> >>> Actually, the fence fixes a problem we discovered with the concurrency >>> torture test suite. The problem occurs with four or more GC threads. >>> If three threads are stealing from the queue of the fourth, two of >>> them can pop the same element. Without a fence between the access >>> to age and bottom in pop_global(), bottom can be older than age. >>> >>> >>> Unfortunately, the OpenJDK implementation with the added fence >>> does not work on AIX. Axel already detected one place where the xlC >>> compiler optimization removed load instruction that is required for >>> the correctness of the algorithm. If we use our access routines with load_acquire >>> (see original webrev below) everything works, unclear why. >>> >>> Now, we think C++ might allow that this load is removed and xlC does >>> the correct, but unexpected thing. On the other hand it might also be >>> a compiler bug. >>> We are currently discussing this with the IBM xlC developers. >>> >>> Best regards, >>> Axel and Goetz. >>> >>> >>> PS: The webrev we proposed originally: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>> >>> >>> >>> >>> >>> > From goetz.lindenmaier at sap.com Tue Mar 19 03:00:32 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Mar 2013 10:00:32 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <514831D5.9000901@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <50D3CAA9.2080104@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF783BE76@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> <51475515.9050908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> <514831D5.9000901@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFAC7B2@DEWDFEMB12A.global.corp.sap> Hi David, To implement dependent-load-+isync you need to know the result register of the load. With OrderAccess::loadload() this is not expressible. As you can see, we use it in load_acquire(), as there we can express the dependency to the register. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 19. M?rz 2013 10:37 To: Lindenmaier, Goetz Cc: John Cuthbertson; Siebenborn, Axel; Vitaly Davidovich; David Chase; Simonis, Volker; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): Memory ordering in taskqueue.hpp Hi Goetz, On 19/03/2013 7:21 PM, Lindenmaier, Goetz wrote: > Hi John, > > Good to see there is work on this! > We'll be happy to test your change, but we are pretty sure it will fail > if you don't issue an isync instruction. > To properly compare our and your implementation we need to > know how you implemented OrderAccess, i.e., file > orderAccess_linux_ppc.inline.hpp. > > If you may not share this file from your closed source, > could you please compare it yourself to our implementation? > Ours is open ;) > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/39fdd72ec591/src/os_cpu/linux_ppc/vm/ Looking at the JMM cookbook: http://g.oswego.edu/dl/jmm/cookbook.html and your implementation, I note that you use explicit fences (lwsync) for loadStore and loadLoad, where it is also possible to introduce a dependent-load+isync to get the same effect. David ----- >> BTW - whatever patch is committed - I intend to make you the contributor. > That's nice, but please account this fix to Axel Siebenborn, he analyzed the bug, > dug out the paper and did the fix. I only do the openJDK contribution. > Anyways, I'm off next week, so he will take over. > > Best regards, > Goetz. > > > > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Montag, 18. M?rz 2013 18:56 > To: Lindenmaier, Goetz > Cc: Vitaly Davidovich; David Chase; Simonis, Volker; David Holmes; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > Hi Geotz, > > I have a patch that I synthesized from yours that I gave to one our > engineers who is working on PowerPC. He was seeing crashes before > applying your patch and mine. With either patch applied, the crashes > disappear. > > The only real difference between our patches is that I only ordered > access to the _bottom field and left accesses to the _age field (and > it's sub fields) unordered. If I give you my patch do you think you > could test with it? It might take a day or two as I want to get the > fixes for the G1 marking bugs committed - the stability of G1 is my > highest priority. > > BTW - whatever patch is committed - I intend to make you the contributor. > > Cheers, > > JohnC > > On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I want to take up this issue again. >> I think we gave a good reason for the fence we added in the taskqueue. >> Do you have any remaining objections against this change? We are >> happy to discuss or adapt the change. >> If not, could somebody please push this change to hotspot? >> >> http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >> >> Best regards, >> Goetz. >> >> >> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >> Sent: Freitag, 8. M?rz 2013 17:13 >> To: Volker Simonis >> Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >> >> >> I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). >> >> Sent from my phone >> On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: >> On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz >> > wrote: >>> Hi Vitaly, >>> >>> the writer has a sync after the write to bottom (see pop_local) >>> but the store and the sync are not one atomic operation. Stuff >>> can happen before the sync is executed. Therefore the reader >>> must sync, too. >>> >> Exactly - you have three threads. The first one executes the write >> to bottom but not the following sync. The second thread reads this >> new value (by chance) and uses it but the third thread still sees the >> old value because there's no multipl-copy-atomicity on PPC. So we >> really need the sync before the read to assure thread three is not seeing >> an older value than thread two. >> >>> Anyways, in pop_global it should be cheaper than in pop_local. >>> >>> Best regards, >>> Geotz. >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 16:13 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >>> Hi Vitaly, >>> >>> No, the problem is not reordering. The problem is that >>> _bottom, which is read after _age, might be older than _age because >>> another processor didn't write it back yet. The fence (sync) makes the >>> current thread wait until it has the new _bottom. >>> On Power, a write is not visible to all other threads simultaneously >>> (no multipl-copy-atomicity). >>> >>> What you propose helps if you look at two processors, but not if >>> four threads on four processors are involved. >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >>> Sent: Freitag, 8. M?rz 2013 15:29 >>> To: Lindenmaier, Goetz >>> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> Hi Goetz, >>> >>> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? >>> >>> Thanks >>> >>> Sent from my phone >>> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >>> Hi, >>> >>> we have been, and still are, doing research on this issue. >>> We want to keep you up to date on this, and propose on the >>> further proceeding. >>> >>> You asked explicit memory ordering operations and a rationale >>> why we added them. >>> >>> Axel found a paper describing the task queue algorithm and the >>> needed ordering on arm and power: >>> Correct and Efficient Work-Stealing for Weak Memory Models; >>> L?, Pop, Cohen, Nardelli; PPoPP'13; >>> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >>> >>> According to this paper we need to add one fence and one load_acquire >>> to your implementation of the task queue. You find this fence in this small >>> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>> >>> With this fence, the algorithm works on Linux for our openjdk ppc >>> port, and also for our SAP JVM . >>> >>> Actually, the fence fixes a problem we discovered with the concurrency >>> torture test suite. The problem occurs with four or more GC threads. >>> If three threads are stealing from the queue of the fourth, two of >>> them can pop the same element. Without a fence between the access >>> to age and bottom in pop_global(), bottom can be older than age. >>> >>> >>> Unfortunately, the OpenJDK implementation with the added fence >>> does not work on AIX. Axel already detected one place where the xlC >>> compiler optimization removed load instruction that is required for >>> the correctness of the algorithm. If we use our access routines with load_acquire >>> (see original webrev below) everything works, unclear why. >>> >>> Now, we think C++ might allow that this load is removed and xlC does >>> the correct, but unexpected thing. On the other hand it might also be >>> a compiler bug. >>> We are currently discussing this with the IBM xlC developers. >>> >>> Best regards, >>> Axel and Goetz. >>> >>> >>> PS: The webrev we proposed originally: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>> >>> >>> >>> >>> >>> > From jesper.wilhelmsson at oracle.com Tue Mar 19 04:21:33 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Mar 2013 12:21:33 +0100 Subject: RFR: 8008783 JPRT target updates In-Reply-To: <51478830.6050607@oracle.com> References: <5142BDDF.9040907@oracle.com> <55E15A2A-0F80-4AA3-BF81-8C25E21358CC@oracle.com> <51478453.9040202@oracle.com> <5147873C.7050704@oracle.com> <51478830.6050607@oracle.com> Message-ID: <51484A3D.9050005@oracle.com> OK, in that case I think it looks good. Ship it! /Jesper On 18/3/13 10:33 PM, David Holmes wrote: > On 19/03/2013 7:29 AM, Jesper Wilhelmsson wrote: >> David, >> >> Your comment in line 106 says that "The ARM GP vfp-sflt build is not >> currently supported" and in the following lines you comment out armvs, >> while in the lines above armvfpsflt is included as a build target. Is >> this correct? > > Yes. armvfpsflt is an embedded platform. armvs is the SE platform for the same > "vfp-sflt" architecture. > > Thanks, > David > >> /Jesper >> >> >> On 18/3/13 10:17 PM, David Holmes wrote: >>> Thanks Chris. >>> >>> Please ignore my previous email seeking a Reviewer. I hadn't realized >>> you were a >>> Reviewer. >>> >>> Still need a second reviewer though. >>> >>> David >>> >>> On 16/03/2013 3:12 AM, Christian Thalinger wrote: >>>> Looks good to me. -- Chris >>>> >>>> On Mar 14, 2013, at 11:21 PM, David Holmes >>>> wrote: >>>> >>>>> The CR for this is not public. These are just some renamings of our >>>>> JPRT >>>>> build targets. >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8008783/webrev/ >>>>> >>>>> This will be pushed via hotspot-emb once some internal changes are >>>>> in place >>>>> to deal with the new names. >>>>> >>>>> I will need a hotspot Reviewer for this please. (You know who you >>>>> are! ;-)) >>>>> >>>>> Thanks, >>>>> David >>>> From coleen.phillimore at oracle.com Tue Mar 19 07:57:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Tue, 19 Mar 2013 10:57:44 -0400 Subject: Review Request: 8009298 and 8009777 In-Reply-To: <513E20BD.3050800@oracle.com> References: <513E20BD.3050800@oracle.com> Message-ID: <51487CE8.3090608@oracle.com> Zhengyu, This looks good. NIce documentation for the flag in globals.hpp. Can you reword slightly: + "Automatically shutdown native memory tracking in stress " \ + "situations. When it is set to false, native memory tracking" \ + "will try its best to stay alive, even if it means that it has to" \ + "sacrifice JVM performance") \ Coleen On 3/11/2013 2:21 PM, Zhengyu Gu wrote: > 8009298: NMT: Special version of class loading/unloading with runThese > stresses out NMT > 8009777: NMT: add new NMT dcmd to control auto shutdown option > > > The two are related. The change is to add an addition VM diagnostic > command-line option "AutoShutdownNMT". > > By default, native memory tracking runtime shuts itself down under > stress situation, and release memory to allow JVM continue running. > But this feature can be undesirable when this is the situation we > really want to know what's happening to JVM memory usage, even that > means that we need to sacrifice JVM performance. > > When AutoShutdownNMT is set to false, NMT will try its best to stay > alive by slowing down threads calling memory allocation/de-allocation. > > Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ > > Tests: > The test case is special version of runThese, it uses 12 threads to > load/unloading classes without executing any tests. > > Following two memory usage graphs show the different behavior with > AutoShutdownNMT on/off. > > AutoShutdownNMT = true > http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png > The steep drop in memory usage was result of shutting down of native > memory tracking. > > AutoShutdownNMT = false > http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png > The steep dig was result of class unloading. > > > Thanks, > > -Zhengyu > From daniel.daugherty at oracle.com Tue Mar 19 08:23:22 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Mar 2013 09:23:22 -0600 Subject: Review Request: 8009298 and 8009777 In-Reply-To: <51487CE8.3090608@oracle.com> References: <513E20BD.3050800@oracle.com> <51487CE8.3090608@oracle.com> Message-ID: <514882EA.6030708@oracle.com> The 2nd -> 4th lines will need a space before the final double-quote to print properly. Dan On 3/19/13 8:57 AM, Coleen Phillmore wrote: > > Zhengyu, > This looks good. NIce documentation for the flag in globals.hpp. Can > you reword slightly: > > + "Automatically shutdown native memory tracking in stress > " \ > + "situations. When it is set to false, native memory > tracking" \ > + "will try its best to stay alive, even if it means that it > has to" \ > + "sacrifice JVM > performance") \ > > > Coleen > > On 3/11/2013 2:21 PM, Zhengyu Gu wrote: >> 8009298: NMT: Special version of class loading/unloading with >> runThese stresses out NMT >> >> 8009777: NMT: add new NMT dcmd to control auto shutdown option >> >> >> The two are related. The change is to add an addition VM diagnostic >> command-line option "AutoShutdownNMT". >> >> By default, native memory tracking runtime shuts itself down under >> stress situation, and release memory to allow JVM continue running. >> But this feature can be undesirable when this is the situation we >> really want to know what's happening to JVM memory usage, even that >> means that we need to sacrifice JVM performance. >> >> When AutoShutdownNMT is set to false, NMT will try its best to stay >> alive by slowing down threads calling memory allocation/de-allocation. >> >> Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ >> >> Tests: >> The test case is special version of runThese, it uses 12 threads to >> load/unloading classes without executing any tests. >> >> Following two memory usage graphs show the different behavior with >> AutoShutdownNMT on/off. >> >> AutoShutdownNMT = true >> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png >> The steep drop in memory usage was result of shutting down of >> native memory tracking. >> >> AutoShutdownNMT = false >> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png >> The steep dig was result of class unloading. >> >> >> Thanks, >> >> -Zhengyu >> > From david.holmes at oracle.com Tue Mar 19 13:13:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Mar 2013 06:13:55 +1000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFAC7B2@DEWDFEMB12A.global.corp.sap> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> <51475515.9050908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> <514831D5.9000901@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC7B2@DEWDFEMB12A.global.corp.sap> Message-ID: <5148C703.9070201@oracle.com> Hi Goetz, On 19/03/2013 8:00 PM, Lindenmaier, Goetz wrote: > Hi David, > > To implement dependent-load-+isync you need to know the result register of the load. > With OrderAccess::loadload() this is not expressible. As you can see, we use it in > load_acquire(), as there we can express the dependency to the register. Sorry I meant to refer to an introduced control-dependency+isync David > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 19. M?rz 2013 10:37 > To: Lindenmaier, Goetz > Cc: John Cuthbertson; Siebenborn, Axel; Vitaly Davidovich; David Chase; Simonis, Volker; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > Hi Goetz, > > On 19/03/2013 7:21 PM, Lindenmaier, Goetz wrote: >> Hi John, >> >> Good to see there is work on this! >> We'll be happy to test your change, but we are pretty sure it will fail >> if you don't issue an isync instruction. >> To properly compare our and your implementation we need to >> know how you implemented OrderAccess, i.e., file >> orderAccess_linux_ppc.inline.hpp. >> >> If you may not share this file from your closed source, >> could you please compare it yourself to our implementation? >> Ours is open ;) >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/39fdd72ec591/src/os_cpu/linux_ppc/vm/ > > Looking at the JMM cookbook: > > http://g.oswego.edu/dl/jmm/cookbook.html > > and your implementation, I note that you use explicit fences (lwsync) > for loadStore and loadLoad, where it is also possible to introduce a > dependent-load+isync to get the same effect. > > David > ----- > >>> BTW - whatever patch is committed - I intend to make you the contributor. >> That's nice, but please account this fix to Axel Siebenborn, he analyzed the bug, >> dug out the paper and did the fix. I only do the openJDK contribution. >> Anyways, I'm off next week, so he will take over. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >> Sent: Montag, 18. M?rz 2013 18:56 >> To: Lindenmaier, Goetz >> Cc: Vitaly Davidovich; David Chase; Simonis, Volker; David Holmes; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >> >> Hi Geotz, >> >> I have a patch that I synthesized from yours that I gave to one our >> engineers who is working on PowerPC. He was seeing crashes before >> applying your patch and mine. With either patch applied, the crashes >> disappear. >> >> The only real difference between our patches is that I only ordered >> access to the _bottom field and left accesses to the _age field (and >> it's sub fields) unordered. If I give you my patch do you think you >> could test with it? It might take a day or two as I want to get the >> fixes for the G1 marking bugs committed - the stability of G1 is my >> highest priority. >> >> BTW - whatever patch is committed - I intend to make you the contributor. >> >> Cheers, >> >> JohnC >> >> On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I want to take up this issue again. >>> I think we gave a good reason for the fence we added in the taskqueue. >>> Do you have any remaining objections against this change? We are >>> happy to discuss or adapt the change. >>> If not, could somebody please push this change to hotspot? >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 17:13 >>> To: Volker Simonis >>> Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker >>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). >>> >>> Sent from my phone >>> On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: >>> On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz >>> > wrote: >>>> Hi Vitaly, >>>> >>>> the writer has a sync after the write to bottom (see pop_local) >>>> but the store and the sync are not one atomic operation. Stuff >>>> can happen before the sync is executed. Therefore the reader >>>> must sync, too. >>>> >>> Exactly - you have three threads. The first one executes the write >>> to bottom but not the following sync. The second thread reads this >>> new value (by chance) and uses it but the third thread still sees the >>> old value because there's no multipl-copy-atomicity on PPC. So we >>> really need the sync before the read to assure thread three is not seeing >>> an older value than thread two. >>> >>>> Anyways, in pop_global it should be cheaper than in pop_local. >>>> >>>> Best regards, >>>> Geotz. >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>>> Sent: Freitag, 8. M?rz 2013 16:13 >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >>>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>>> >>>> >>>> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >>>> Hi Vitaly, >>>> >>>> No, the problem is not reordering. The problem is that >>>> _bottom, which is read after _age, might be older than _age because >>>> another processor didn't write it back yet. The fence (sync) makes the >>>> current thread wait until it has the new _bottom. >>>> On Power, a write is not visible to all other threads simultaneously >>>> (no multipl-copy-atomicity). >>>> >>>> What you propose helps if you look at two processors, but not if >>>> four threads on four processors are involved. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >>>> Sent: Freitag, 8. M?rz 2013 15:29 >>>> To: Lindenmaier, Goetz >>>> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >>>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>>> >>>> >>>> Hi Goetz, >>>> >>>> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? > >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >>>> Hi, >>>> >>>> we have been, and still are, doing research on this issue. >>>> We want to keep you up to date on this, and propose on the >>>> further proceeding. >>>> >>>> You asked explicit memory ordering operations and a rationale >>>> why we added them. >>>> >>>> Axel found a paper describing the task queue algorithm and the >>>> needed ordering on arm and power: >>>> Correct and Efficient Work-Stealing for Weak Memory Models; >>>> L?, Pop, Cohen, Nardelli; PPoPP'13; >>>> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >>>> >>>> According to this paper we need to add one fence and one load_acquire >>>> to your implementation of the task queue. You find this fence in this small >>>> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>>> >>>> With this fence, the algorithm works on Linux for our openjdk ppc >>>> port, and also for our SAP JVM . >>>> >>>> Actually, the fence fixes a problem we discovered with the concurrency >>>> torture test suite. The problem occurs with four or more GC threads. >>>> If three threads are stealing from the queue of the fourth, two of >>>> them can pop the same element. Without a fence between the access >>>> to age and bottom in pop_global(), bottom can be older than age. >>>> >>>> >>>> Unfortunately, the OpenJDK implementation with the added fence >>>> does not work on AIX. Axel already detected one place where the xlC >>>> compiler optimization removed load instruction that is required for >>>> the correctness of the algorithm. If we use our access routines with load_acquire >>>> (see original webrev below) everything works, unclear why. >>>> >>>> Now, we think C++ might allow that this load is removed and xlC does >>>> the correct, but unexpected thing. On the other hand it might also be >>>> a compiler bug. >>>> We are currently discussing this with the IBM xlC developers. >>>> >>>> Best regards, >>>> Axel and Goetz. >>>> >>>> >>>> PS: The webrev we proposed originally: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>>> >>>> >>>> >>>> >>>> >>>> >> From mandy.chung at oracle.com Tue Mar 19 13:14:41 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 13:14:41 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: <5148C731.3050500@oracle.com> I do a partial review in particular to make sure the jdk and hotspot change are in sync. javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Mandy On 3/14/13 8:31 PM, Christian Thalinger wrote: > [This is the HotSpot part of JEP 176] > > http://cr.openjdk.java.net/~twisti/7198429 > > 7198429: need checked categorization of caller-sensitive methods in the JDK > Reviewed-by: > > More information in JEP 176: > > http://openjdk.java.net/jeps/176 > > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/classFileParser.hpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/oops/method.cpp > src/share/vm/oops/method.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/prims/jvm.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/prims/unsafe.cpp > src/share/vm/runtime/vframe.cpp > src/share/vm/runtime/vframe.hpp > From zhengyu.gu at oracle.com Tue Mar 19 13:45:57 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 19 Mar 2013 16:45:57 -0400 Subject: Review Request: 8009298 and 8009777 In-Reply-To: <514882EA.6030708@oracle.com> References: <513E20BD.3050800@oracle.com> <51487CE8.3090608@oracle.com> <514882EA.6030708@oracle.com> Message-ID: <5148CE85.4030002@oracle.com> Updated webrev based on Coleen and Dan's comment. http://cr.openjdk.java.net/~zgu/8009298/webrev.01/ Thanks, -Zhengyu On 3/19/2013 11:23 AM, Daniel D. Daugherty wrote: > The 2nd -> 4th lines will need a space before the final double-quote > to print properly. > > Dan > > > On 3/19/13 8:57 AM, Coleen Phillmore wrote: >> >> Zhengyu, >> This looks good. NIce documentation for the flag in globals.hpp. >> Can you reword slightly: >> >> + "Automatically shutdown native memory tracking in stress >> " \ >> + "situations. When it is set to false, native memory >> tracking" \ >> + "will try its best to stay alive, even if it means that >> it has to" \ >> + "sacrifice JVM >> performance") \ >> >> >> Coleen >> >> On 3/11/2013 2:21 PM, Zhengyu Gu wrote: >>> 8009298: NMT: Special version of class loading/unloading with >>> runThese stresses out NMT >>> >>> 8009777: NMT: add new NMT dcmd to control auto shutdown option >>> >>> >>> The two are related. The change is to add an addition VM diagnostic >>> command-line option "AutoShutdownNMT". >>> >>> By default, native memory tracking runtime shuts itself down under >>> stress situation, and release memory to allow JVM continue running. >>> But this feature can be undesirable when this is the situation we >>> really want to know what's happening to JVM memory usage, even that >>> means that we need to sacrifice JVM performance. >>> >>> When AutoShutdownNMT is set to false, NMT will try its best to stay >>> alive by slowing down threads calling memory allocation/de-allocation. >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ >>> >>> Tests: >>> The test case is special version of runThese, it uses 12 threads to >>> load/unloading classes without executing any tests. >>> >>> Following two memory usage graphs show the different behavior with >>> AutoShutdownNMT on/off. >>> >>> AutoShutdownNMT = true >>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png >>> The steep drop in memory usage was result of shutting down of >>> native memory tracking. >>> >>> AutoShutdownNMT = false >>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png >>> The steep dig was result of class unloading. >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From coleen.phillimore at oracle.com Tue Mar 19 14:11:38 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Mar 2013 17:11:38 -0400 Subject: Review Request: 8009298 and 8009777 In-Reply-To: <5148CE85.4030002@oracle.com> References: <513E20BD.3050800@oracle.com> <51487CE8.3090608@oracle.com> <514882EA.6030708@oracle.com> <5148CE85.4030002@oracle.com> Message-ID: <5148D48A.2070203@oracle.com> Good. Coleen On 3/19/2013 4:45 PM, Zhengyu Gu wrote: > Updated webrev based on Coleen and Dan's comment. > > http://cr.openjdk.java.net/~zgu/8009298/webrev.01/ > > > Thanks, > > -Zhengyu > > On 3/19/2013 11:23 AM, Daniel D. Daugherty wrote: >> The 2nd -> 4th lines will need a space before the final double-quote >> to print properly. >> >> Dan >> >> >> On 3/19/13 8:57 AM, Coleen Phillmore wrote: >>> >>> Zhengyu, >>> This looks good. NIce documentation for the flag in globals.hpp. >>> Can you reword slightly: >>> >>> + "Automatically shutdown native memory tracking in stress >>> " \ >>> + "situations. When it is set to false, native memory >>> tracking" \ >>> + "will try its best to stay alive, even if it means that >>> it has to" \ >>> + "sacrifice JVM >>> performance") \ >>> >>> >>> Coleen >>> >>> On 3/11/2013 2:21 PM, Zhengyu Gu wrote: >>>> 8009298: NMT: Special version of class loading/unloading with >>>> runThese stresses out NMT >>>> >>>> 8009777: NMT: add new NMT dcmd to control auto shutdown option >>>> >>>> >>>> The two are related. The change is to add an addition VM diagnostic >>>> command-line option "AutoShutdownNMT". >>>> >>>> By default, native memory tracking runtime shuts itself down under >>>> stress situation, and release memory to allow JVM continue running. >>>> But this feature can be undesirable when this is the situation we >>>> really want to know what's happening to JVM memory usage, even that >>>> means that we need to sacrifice JVM performance. >>>> >>>> When AutoShutdownNMT is set to false, NMT will try its best to stay >>>> alive by slowing down threads calling memory allocation/de-allocation. >>>> >>>> Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ >>>> >>>> Tests: >>>> The test case is special version of runThese, it uses 12 threads to >>>> load/unloading classes without executing any tests. >>>> >>>> Following two memory usage graphs show the different behavior with >>>> AutoShutdownNMT on/off. >>>> >>>> AutoShutdownNMT = true >>>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png >>>> The steep drop in memory usage was result of shutting down of >>>> native memory tracking. >>>> >>>> AutoShutdownNMT = false >>>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png >>>> The steep dig was result of class unloading. >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>> >> > From jesper.wilhelmsson at oracle.com Tue Mar 19 14:30:29 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 19 Mar 2013 21:30:29 +0000 Subject: hg: hsx/hsx24/hotspot: 8010227: Remove promotion failed boolean from YC event Message-ID: <20130319213043.94FAB4826D@hg.openjdk.java.net> Changeset: 0a5dbad3cd92 Author: jwilhelm Date: 2013-03-19 18:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0a5dbad3cd92 8010227: Remove promotion failed boolean from YC event Summary: Remove promotion failed boolean from YC event Reviewed-by: dholmes, brutisso ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/trace/trace.xml From zhengyu.gu at oracle.com Tue Mar 19 14:38:31 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 19 Mar 2013 17:38:31 -0400 Subject: Review Request: 8009298 and 8009777 In-Reply-To: <5148D48A.2070203@oracle.com> References: <513E20BD.3050800@oracle.com> <51487CE8.3090608@oracle.com> <514882EA.6030708@oracle.com> <5148CE85.4030002@oracle.com> <5148D48A.2070203@oracle.com> Message-ID: <5148DAD7.9000302@oracle.com> Thanks, -Zhengyu On 3/19/2013 5:11 PM, Coleen Phillimore wrote: > > Good. > Coleen > > On 3/19/2013 4:45 PM, Zhengyu Gu wrote: >> Updated webrev based on Coleen and Dan's comment. >> >> http://cr.openjdk.java.net/~zgu/8009298/webrev.01/ >> >> >> Thanks, >> >> -Zhengyu >> >> On 3/19/2013 11:23 AM, Daniel D. Daugherty wrote: >>> The 2nd -> 4th lines will need a space before the final double-quote >>> to print properly. >>> >>> Dan >>> >>> >>> On 3/19/13 8:57 AM, Coleen Phillmore wrote: >>>> >>>> Zhengyu, >>>> This looks good. NIce documentation for the flag in globals.hpp. >>>> Can you reword slightly: >>>> >>>> + "Automatically shutdown native memory tracking in >>>> stress " \ >>>> + "situations. When it is set to false, native memory >>>> tracking" \ >>>> + "will try its best to stay alive, even if it means that >>>> it has to" \ >>>> + "sacrifice JVM >>>> performance") \ >>>> >>>> >>>> Coleen >>>> >>>> On 3/11/2013 2:21 PM, Zhengyu Gu wrote: >>>>> 8009298: NMT: Special version of class loading/unloading with >>>>> runThese stresses out NMT >>>>> >>>>> 8009777: NMT: add new NMT dcmd to control auto shutdown option >>>>> >>>>> >>>>> The two are related. The change is to add an addition VM >>>>> diagnostic command-line option "AutoShutdownNMT". >>>>> >>>>> By default, native memory tracking runtime shuts itself down under >>>>> stress situation, and release memory to allow JVM continue >>>>> running. But this feature can be undesirable when this is the >>>>> situation we really want to know what's happening to JVM memory >>>>> usage, even that means that we need to sacrifice JVM performance. >>>>> >>>>> When AutoShutdownNMT is set to false, NMT will try its best to >>>>> stay alive by slowing down threads calling memory >>>>> allocation/de-allocation. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~zgu/8009298/webrev.00/ >>>>> >>>>> Tests: >>>>> The test case is special version of runThese, it uses 12 threads >>>>> to load/unloading classes without executing any tests. >>>>> >>>>> Following two memory usage graphs show the different behavior with >>>>> AutoShutdownNMT on/off. >>>>> >>>>> AutoShutdownNMT = true >>>>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/autoShutdown.png >>>>> The steep drop in memory usage was result of shutting down of >>>>> native memory tracking. >>>>> >>>>> AutoShutdownNMT = false >>>>> http://cr.openjdk.java.net/~zgu/8009298/webrev.00/noAutoShutdown.png >>>>> The steep dig was result of class unloading. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>> >>> >> > From jesper.wilhelmsson at oracle.com Tue Mar 19 17:06:06 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 20 Mar 2013 00:06:06 +0000 Subject: hg: hsx/hsx24/hotspot: 8008790: Promotion failed tracing event for all GCs Message-ID: <20130320000611.324E248277@hg.openjdk.java.net> Changeset: 47b5859d4634 Author: jwilhelm Date: 2013-03-19 23:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/47b5859d4634 8008790: Promotion failed tracing event for all GCs Summary: Implemented promotion failed event for ParNew and Serial GC Reviewed-by: brutisso, ehelin ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/gc_implementation/shared/promotionFailedInfo.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/trace/trace.xml From john.r.rose at oracle.com Tue Mar 19 17:21:11 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:21:11 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: On Mar 14, 2013, at 8:31 PM, Christian Thalinger wrote: > [This is the HotSpot part of JEP 176] > > http://cr.openjdk.java.net/~twisti/7198429 > > 7198429: need checked categorization of caller-sensitive methods in the JDK > Reviewed-by: Over all, great work on a tricky problem. I'd add a few asserts and tweak a couple of lines; see below. Reviewed as is or with suggested changes. ? John --- Method::is_ignored_by_security_stack_walk I would like to see reflect_invoke_cache go away some day. Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check? (I realize this is a question mainly for folks working on JVMTI.) --- JVM_GetCallerClass Suggest an assert for vfst.method() == NULL. Should not happen, and previous code would apparently have crashed already, but... (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded. Should not happen.) --- JVM_GetClassContext What do these lines do: + // Collect method holders + GrowableArray* klass_array = new GrowableArray(); It looks like a paste-o from another source base. --- LibraryCallKit::inline_native_Reflection_getCallerClass I believe this assertion, but I would prefer to see it checked more forcibly: + // NOTE: Start the loop at depth 1 because the current JVM state does + // not include the Reflection.getCallerClass() frame. Not sure there is a good way to do this. But, perhaps put the comment here: case 0: // ...comment... ShouldNotReachHere(); Also, if something goes wrong with caller sensitivity, we just get a "return false". Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message? That makes it slightly easier to see what happened. The LogCompilation switch should leave a "paper trail". Actually, I see that LogCompilation doesn't mention failed intrinsic inlines. Rats. At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug. --- JVM_RegisterUnsafeMethods That's an improvement. Thanks. (A nagging worry: How big are those static tables getting?) --- vframeStreamCommon::security_get_caller_frame This now does something odd if depth < 0. Suggest an assert. From christian.thalinger at oracle.com Tue Mar 19 17:29:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 17:29:58 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5148C731.3050500@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> Message-ID: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > I do a partial review in particular to make sure the jdk and hotspot change are in sync. > > javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? > > 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected > 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes They can have the same value because they are used for different things in different places. I talked to John about this and he said that the MN_SEARCH_* guys don't add much value and might be removed. > > > method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. Right. I forgot to add that code. Here is an incremental webrev: http://cr.openjdk.java.net/~twisti/7198429/edit/ And the full thing: http://cr.openjdk.java.net/~twisti/7198429/ Let me know if that works for you. > > If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? Not easily. We set a flag on the method when parse the class. At that point we decide if the annotation is there or not. If the annotation is not allowed in parsed class because it's not loaded by the right class loader then it does not "exist". > > jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Yes. I talked to Vladimir about that yesterday. The better solution seems to be to leave the old entry point. If we add a new one that kind of adds a new method to the "official" VM interface. Other VM implementors would have to implement that one as well because the JDK then links to this new method. Thanks for the review! -- Chris > > Mandy > > > On 3/14/13 8:31 PM, Christian Thalinger wrote: >> [This is the HotSpot part of JEP 176] >> >> http://cr.openjdk.java.net/~twisti/7198429 >> >> 7198429: need checked categorization of caller-sensitive methods in the JDK >> Reviewed-by: >> >> More information in JEP 176: >> >> http://openjdk.java.net/jeps/176 >> >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciMethod.hpp >> src/share/vm/classfile/classFileParser.cpp >> src/share/vm/classfile/classFileParser.hpp >> src/share/vm/classfile/javaClasses.hpp >> src/share/vm/classfile/systemDictionary.hpp >> src/share/vm/classfile/vmSymbols.hpp >> src/share/vm/oops/method.cpp >> src/share/vm/oops/method.hpp >> src/share/vm/opto/library_call.cpp >> src/share/vm/prims/jvm.cpp >> src/share/vm/prims/methodHandles.cpp >> src/share/vm/prims/unsafe.cpp >> src/share/vm/runtime/vframe.cpp >> src/share/vm/runtime/vframe.hpp >> > From john.r.rose at oracle.com Tue Mar 19 17:39:32 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:39:32 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <5148C731.3050500@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> Message-ID: On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? > > 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected > 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes That's OK; they are used with different arguments, as the nearby comments point out. > method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. Oops, that needs fixing. For simplicity, I suggest you adjust the boolean 'privileged' that controls the ad hoc category of code that benefits from the annotation parsing. The important property of such code is that it is statically configured with the JVM, not dynamically loaded. > If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? Maybe not, if it would involve reparsing the annotations. The error message can mention that the offending method is off the BCP so that even if it _were_ annotated the annotation would not count. We don't need a very user-friendly message here, as long as it points out that there is an offending off-label use of a JVM primitive. Nobody calls JVM_GetCallerClass by accident, and even if an end user is the unlucky discoverer, if the JVM message says "illegal internal method call" or some such, the bug should be clear enough. > jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. Good point. I'm fine with either option. ? John From john.r.rose at oracle.com Tue Mar 19 17:42:17 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Mar 2013 17:42:17 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> Message-ID: On Mar 19, 2013, at 5:29 PM, Christian Thalinger wrote: > Right. I forgot to add that code. Here is an incremental webrev: > > http://cr.openjdk.java.net/~twisti/7198429/edit/ > > And the full thing: > > http://cr.openjdk.java.net/~twisti/7198429/ > > Let me know if that works for you. Good for me. ? John From christian.thalinger at oracle.com Tue Mar 19 18:02:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 18:02:53 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> Message-ID: <7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com> On Mar 19, 2013, at 5:21 PM, John Rose wrote: > On Mar 14, 2013, at 8:31 PM, Christian Thalinger wrote: > >> [This is the HotSpot part of JEP 176] >> >> http://cr.openjdk.java.net/~twisti/7198429 >> >> 7198429: need checked categorization of caller-sensitive methods in the JDK >> Reviewed-by: > > > Over all, great work on a tricky problem. I'd add a few asserts and tweak a couple of lines; see below. Reviewed as is or with suggested changes. ? John > > --- Method::is_ignored_by_security_stack_walk > I would like to see reflect_invoke_cache go away some day. Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check? (I realize this is a question mainly for folks working on JVMTI.) That's what I tried to do: if the intrinsic_id == _invoke it also must be the same method in reflect_invoke_cache. More than that would mean to enhance ActiveMethodOopsCache because you can't ask for methods in the cache. > > --- JVM_GetCallerClass > Suggest an assert for vfst.method() == NULL. Should not happen, and previous code would apparently have crashed already, but... > > (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded. Should not happen.) Sure, I can add that assert but there is other code in jvm.cpp that relies on the fact that vfst.method() is non-null. We should add asserts in all that places but that's for another RFE. > > --- JVM_GetClassContext > What do these lines do: > + // Collect method holders > + GrowableArray* klass_array = new GrowableArray(); > > It looks like a paste-o from another source base. Left over. I filed an RFE for that improvement: JDK-8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > > --- LibraryCallKit::inline_native_Reflection_getCallerClass > > I believe this assertion, but I would prefer to see it checked more forcibly: > + // NOTE: Start the loop at depth 1 because the current JVM state does > + // not include the Reflection.getCallerClass() frame. > > Not sure there is a good way to do this. But, perhaps put the comment here: > case 0: > // ...comment... > ShouldNotReachHere(); How about: case 0: fatal("current JVM state does not include the Reflection.getCallerClass() frame"); break; > > Also, if something goes wrong with caller sensitivity, we just get a "return false". Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message? That makes it slightly easier to see what happened. It seems easier to add printing code to the case statement: case 1: // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass). if (!m->caller_sensitive()) { #ifndef PRODUCT if ((PrintIntrinsics || PrintInlining || PrintOptoInlining) && Verbose) { tty->print_cr(" Bailing out: CallerSensitive annotation expected at frame %d", n); } #endif return false; // bail-out; let JVM_GetCallerClass do the work } break; > > The LogCompilation switch should leave a "paper trail". Actually, I see that LogCompilation doesn't mention failed intrinsic inlines. Rats. At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug. > > --- JVM_RegisterUnsafeMethods > That's an improvement. Thanks. > > (A nagging worry: How big are those static tables getting?) We could remove some very old ones like 1.4.0 and 1.4.1. This time, next time? > > --- vframeStreamCommon::security_get_caller_frame > This now does something odd if depth < 0. Suggest an assert. The behavior with depth < 0 in the current code is even worse. An assert is a good idea. As discussed I want to remove that method in the future because its uses are dubious. -- Chris From mandy.chung at oracle.com Tue Mar 19 18:02:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Mar 2013 18:02:16 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <5148C731.3050500@oracle.com> <3CE4823C-BB63-44C4-B6E6-C8AC4D1E29E0@oracle.com> Message-ID: <51490A98.7080003@oracle.com> On 3/19/2013 5:29 PM, Christian Thalinger wrote: > On Mar 19, 2013, at 1:14 PM, Mandy Chung wrote: > >> I do a partial review in particular to make sure the jdk and hotspot change are in sync. >> >> javaClasses.hpp - MN_CALLER_SENSITIVE and MN_SEARCH_SUPERCLASSES have the same value. Should they be different? >> >> 1057 MN_CALLER_SENSITIVE = 0x00100000, // @CallerSensitive annotation detected >> 1061 MN_SEARCH_SUPERCLASSES = 0x00100000, // walk super classes > They can have the same value because they are used for different things in different places. I talked to John about this and he said that the MN_SEARCH_* guys don't add much value and might be removed. Thanks. That's fine. >> >> method.hpp - Is caller_sensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive. > Right. I forgot to add that code. Here is an incremental webrev: > > http://cr.openjdk.java.net/~twisti/7198429/edit/ > > And the full thing: > > http://cr.openjdk.java.net/~twisti/7198429/ > > Let me know if that works for you. I'll take your patch and let you know. >> If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)? > Not easily. We set a flag on the method when parse the class. At that point we decide if the annotation is there or not. If the annotation is not allowed in parsed class because it's not loaded by the right class loader then it does not "exist". 701 THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), err_msg("CallerSensitive annotation expected at frame %d", n)); Perhaps it could check the class loader of the class of the method or print out additional info? It should be rare to run into this error but it would greatly help diagnosing the problem if @CS method loaded by unexpected class loader. >> jvm.cpp: have you considered adding a new entry point instead of having JVM_GetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVM_GetCallerClass(int) in the future. I am fine with either approach but just to bring it up. > Yes. I talked to Vladimir about that yesterday. The better solution seems to be to leave the old entry point. If we add a new one that kind of adds a new method to the "official" VM interface. Other VM implementors would have to implement that one as well because the JDK then links to this new method. > Yup, that's one of the cons of adding a new entry point. Other VM implementation may need to support JVM_GetCallerClass(-1) to run on our JDK library implementation in either approach. Good and keep the code entry point. I'll send out the jdk change for code review. Mandy From christian.thalinger at oracle.com Tue Mar 19 18:16:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 18:16:14 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: > > On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > >> >> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >> >>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>> >>>>>> This would be the first of three fixes: >>>>>> >>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>> >>>>> This logic is not suitable: >>>>> >>>>> 541 # Testing the built JVM >>>>> 542 ifeq ($(JAVA_HOME),) >>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>> 544 else >>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>> 546 endif >>>>> >>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>> >>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>> >>> This is so confusing. Our makefiles are an abomination! >> >> I couldn't agree more. >> >>> >>> So this all started because the makefile has: >>> >>> JAVA_HOME=$(ABS_BOOTDIR) >>> >>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>> >>> So how did the boot JDK come back into this??? >>> >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>> >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>> >>>> And here comes this little snippet into play: >>>> >>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>> >>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? > > Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: > > ifdef ALT_BOOTDIR > > COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac > > else > > ifdef BOOTDIR > > COMPILE.JAVAC = $(BOOTDIR)/bin/javac > > else > > ifdef JAVA_HOME > else > > endif > endif > endif > > BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. Any reviewers who approve or veto pushing this change? -- Chris > > This all sucks and needs to be replaced by something completely different. Soon. > > -- Chris > >>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >> >> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >> >> -- Chris >> >>> >>> Thanks, >>> David >>> >>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>> >>>>> >>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>> >>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>> >>>>> >>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>> >>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>> >>>> -- Chris >>>> >>>>> >>>>> And this addition still makes no sense to me: >>>>> >>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>> >>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>> >>>>> David >>>>> >>>>> >>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>> >>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>> >>>>>> -- Chris >>>>>> >>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>> >>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>> >>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>> >>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>> >>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>> >>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>> running test_gamma. >>>>>>>>> >>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>> make/defs.make >>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > From coleen.phillimore at oracle.com Tue Mar 19 18:22:48 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Mar 2013 21:22:48 -0400 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> Message-ID: <51490F68.10209@oracle.com> What is the final webrev? Does this include "hotspot" fix to not use the launcher in the vm repository but still allow debugging with -gdb? Does TEST_IN_BUILD go away? thanks, Coleen On 3/19/2013 9:16 PM, Christian Thalinger wrote: > On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: > >> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >> >>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>> >>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>> >>>>>>> This would be the first of three fixes: >>>>>>> >>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>> This logic is not suitable: >>>>>> >>>>>> 541 # Testing the built JVM >>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>> 544 else >>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>> 546 endif >>>>>> >>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>> This is so confusing. Our makefiles are an abomination! >>> I couldn't agree more. >>> >>>> So this all started because the makefile has: >>>> >>>> JAVA_HOME=$(ABS_BOOTDIR) >>>> >>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>> >>>> So how did the boot JDK come back into this??? >>>> >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>> >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>> >>>>> And here comes this little snippet into play: >>>>> >>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>> >>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >> >> ifdef ALT_BOOTDIR >> >> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >> >> else >> >> ifdef BOOTDIR >> >> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >> >> else >> >> ifdef JAVA_HOME >> else >> >> endif >> endif >> endif >> >> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). > Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. > > Any reviewers who approve or veto pushing this change? > > -- Chris > >> This all sucks and needs to be replaced by something completely different. Soon. >> >> -- Chris >> >>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>> >>> -- Chris >>> >>>> Thanks, >>>> David >>>> >>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>> >>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>> >>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>> >>>>> -- Chris >>>>> >>>>>> And this addition still makes no sense to me: >>>>>> >>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>> >>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>> >>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>> >>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>> >>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>> Reviewed-by: >>>>>>>>>> >>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>> >>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>> running test_gamma. >>>>>>>>>> >>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>> make/defs.make >>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>> From vladimir.kozlov at oracle.com Tue Mar 19 19:16:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Mar 2013 19:16:45 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> Message-ID: <51491C0D.7020906@oracle.com> Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. The next looks strange: + test_fastdebug: generic_test + test_fastdebug: VM_FLAVOR=fastdebug May be it is time to let Queens go and use -help as you suggested or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). Vladimir On 3/19/13 6:16 PM, Christian Thalinger wrote: > > On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: > >> >> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >> >>> >>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>> >>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>> >>>>>>> This would be the first of three fixes: >>>>>>> >>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>> >>>>>> This logic is not suitable: >>>>>> >>>>>> 541 # Testing the built JVM >>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>> 544 else >>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>> 546 endif >>>>>> >>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>> >>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>> >>>> This is so confusing. Our makefiles are an abomination! >>> >>> I couldn't agree more. >>> >>>> >>>> So this all started because the makefile has: >>>> >>>> JAVA_HOME=$(ABS_BOOTDIR) >>>> >>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>> >>>> So how did the boot JDK come back into this??? >>>> >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>> >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>> >>>>> And here comes this little snippet into play: >>>>> >>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>> >>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>> >>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >> >> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >> >> ifdef ALT_BOOTDIR >> >> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >> >> else >> >> ifdef BOOTDIR >> >> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >> >> else >> >> ifdef JAVA_HOME >> else >> >> endif >> endif >> endif >> >> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). > > Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. > > Any reviewers who approve or veto pushing this change? > > -- Chris > >> >> This all sucks and needs to be replaced by something completely different. Soon. >> >> -- Chris >> >>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>> >>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>> >>>>>> >>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>> >>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>> >>>>>> >>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>> >>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> And this addition still makes no sense to me: >>>>>> >>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>> >>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>> >>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> >>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>> >>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>> >>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>> >>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>> Reviewed-by: >>>>>>>>>> >>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>> >>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>> running test_gamma. >>>>>>>>>> >>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>> make/defs.make >>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From goetz.lindenmaier at sap.com Wed Mar 20 02:34:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Mar 2013 09:34:12 +0000 Subject: RFR(M): Memory ordering in taskqueue.hpp In-Reply-To: <5148C703.9070201@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp> <510327E8.2020907@oracle.com> <047B1E2ED51BB242803D2C392229AD370A48921020@DEWDFECCR03.wdf.sap.corp> <4295855A5C1DE049A61835A1887419CC0CFA9A9B@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9AF7@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFA9B1E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC0CFAC291@DEWDFEMB12A.global.corp.sap> <51475515.9050908@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC756@DEWDFEMB12A.global.corp.sap> <514831D5.9000901@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFAC7B2@DEWDFEMB12A.global.corp.sap> <5148C703.9070201@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0CFACC8B@DEWDFEMB12A.global.corp.sap> Hi David, as we understand, you can not do this in the existing loadload and loadstore methods, as also for the control-dependency you need the dependency to the load that must be ordered. I.e., if you implement it like this: OrderAccess::loadload() { __asm__ __volatile__ ("cmp cr0 R0, R0; bne target; isync; label: target") } there is no dependency to a load to be ordered. You could add new methods to OrderAccess as loadload_afterDependentBranch which does an isync, and may only be called if the C-code does a branch depending on the volatile load, e.g. b = *(volatile int*)x; if (b) { OrderAccess::loadload_afterDependentBranch(); ... further loads or stores which need ordering } LoadStore similarly. Further, this instruction sequence orders only one load (load of x in the example) against all following ones, while we understood that the loadload() method must order all preceding loads wrt. all succeeding ones. By the way, cmp bne is more expensive than twi we use in load_acquire. Best regards, Goetz and Martin -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 19. M?rz 2013 21:14 To: Lindenmaier, Goetz Cc: John Cuthbertson; Siebenborn, Axel; Vitaly Davidovich; David Chase; Simonis, Volker; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): Memory ordering in taskqueue.hpp Hi Goetz, On 19/03/2013 8:00 PM, Lindenmaier, Goetz wrote: > Hi David, > > To implement dependent-load-+isync you need to know the result register of the load. > With OrderAccess::loadload() this is not expressible. As you can see, we use it in > load_acquire(), as there we can express the dependency to the register. Sorry I meant to refer to an introduced control-dependency+isync David > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 19. M?rz 2013 10:37 > To: Lindenmaier, Goetz > Cc: John Cuthbertson; Siebenborn, Axel; Vitaly Davidovich; David Chase; Simonis, Volker; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp > > Hi Goetz, > > On 19/03/2013 7:21 PM, Lindenmaier, Goetz wrote: >> Hi John, >> >> Good to see there is work on this! >> We'll be happy to test your change, but we are pretty sure it will fail >> if you don't issue an isync instruction. >> To properly compare our and your implementation we need to >> know how you implemented OrderAccess, i.e., file >> orderAccess_linux_ppc.inline.hpp. >> >> If you may not share this file from your closed source, >> could you please compare it yourself to our implementation? >> Ours is open ;) >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/39fdd72ec591/src/os_cpu/linux_ppc/vm/ > > Looking at the JMM cookbook: > > http://g.oswego.edu/dl/jmm/cookbook.html > > and your implementation, I note that you use explicit fences (lwsync) > for loadStore and loadLoad, where it is also possible to introduce a > dependent-load+isync to get the same effect. > > David > ----- > >>> BTW - whatever patch is committed - I intend to make you the contributor. >> That's nice, but please account this fix to Axel Siebenborn, he analyzed the bug, >> dug out the paper and did the fix. I only do the openJDK contribution. >> Anyways, I'm off next week, so he will take over. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >> Sent: Montag, 18. M?rz 2013 18:56 >> To: Lindenmaier, Goetz >> Cc: Vitaly Davidovich; David Chase; Simonis, Volker; David Holmes; hotspot-dev at openjdk.java.net >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >> >> Hi Geotz, >> >> I have a patch that I synthesized from yours that I gave to one our >> engineers who is working on PowerPC. He was seeing crashes before >> applying your patch and mine. With either patch applied, the crashes >> disappear. >> >> The only real difference between our patches is that I only ordered >> access to the _bottom field and left accesses to the _age field (and >> it's sub fields) unordered. If I give you my patch do you think you >> could test with it? It might take a day or two as I want to get the >> fixes for the G1 marking bugs committed - the stability of G1 is my >> highest priority. >> >> BTW - whatever patch is committed - I intend to make you the contributor. >> >> Cheers, >> >> JohnC >> >> On 3/18/2013 3:27 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I want to take up this issue again. >>> I think we gave a good reason for the fence we added in the taskqueue. >>> Do you have any remaining objections against this change? We are >>> happy to discuss or adapt the change. >>> If not, could somebody please push this change to hotspot? >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>> Sent: Freitag, 8. M?rz 2013 17:13 >>> To: Volker Simonis >>> Cc: hotspot-dev at openjdk.java.net; David Holmes; Lindenmaier, Goetz; Simonis, Volker >>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp >>> >>> >>> I see, thanks for the explanation guys. Is there no atomic/locked (in x86 sense) store instruction on power? Is that what you mean by multiple atomicity? Not familiar with power, so being ignorant :). >>> >>> Sent from my phone >>> On Mar 8, 2013 11:08 AM, "Volker Simonis" > wrote: >>> On Fri, Mar 8, 2013 at 4:31 PM, Lindenmaier, Goetz >>> > wrote: >>>> Hi Vitaly, >>>> >>>> the writer has a sync after the write to bottom (see pop_local) >>>> but the store and the sync are not one atomic operation. Stuff >>>> can happen before the sync is executed. Therefore the reader >>>> must sync, too. >>>> >>> Exactly - you have three threads. The first one executes the write >>> to bottom but not the following sync. The second thread reads this >>> new value (by chance) and uses it but the third thread still sees the >>> old value because there's no multipl-copy-atomicity on PPC. So we >>> really need the sync before the read to assure thread three is not seeing >>> an older value than thread two. >>> >>>> Anyways, in pop_global it should be cheaper than in pop_local. >>>> >>>> Best regards, >>>> Geotz. >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com] >>>> Sent: Freitag, 8. M?rz 2013 16:13 >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-dev at openjdk.java.net; David Holmes; John Cuthbertson; Simonis, Volker >>>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>>> >>>> >>>> Hmm, if load fences on the reader aren't sufficient, seems like the problem is missing order/fence on the writer? If the write isn't visible to all processors immediately on power, shouldn't there be a fence in the write to ensure all CPUs see it? Putting the fence in the reader seems odd, but maybe that's just me. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> On Mar 8, 2013 10:03 AM, "Lindenmaier, Goetz" >> wrote: >>>> Hi Vitaly, >>>> >>>> No, the problem is not reordering. The problem is that >>>> _bottom, which is read after _age, might be older than _age because >>>> another processor didn't write it back yet. The fence (sync) makes the >>>> current thread wait until it has the new _bottom. >>>> On Power, a write is not visible to all other threads simultaneously >>>> (no multipl-copy-atomicity). >>>> >>>> What you propose helps if you look at two processors, but not if >>>> four threads on four processors are involved. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> From: Vitaly Davidovich [mailto:vitalyd at gmail.com>] >>>> Sent: Freitag, 8. M?rz 2013 15:29 >>>> To: Lindenmaier, Goetz >>>> Cc: David Holmes; hotspot-dev at openjdk.java.net>; John Cuthbertson; Simonis, Volker >>>> Subject: RE: RFR(M): Memory ordering in taskqueue.hpp >>>> >>>> >>>> Hi Goetz, >>>> >>>> If I understand correctly the problem is that bottom is loaded before age via compiler or arch reordering. But why is a full fence needed? Is it not sufficient to have just a load fence to load age and relaxed load (just compiler barrier) for bottom? > >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> On Mar 8, 2013 9:06 AM, "Lindenmaier, Goetz" >> wrote: >>>> Hi, >>>> >>>> we have been, and still are, doing research on this issue. >>>> We want to keep you up to date on this, and propose on the >>>> further proceeding. >>>> >>>> You asked explicit memory ordering operations and a rationale >>>> why we added them. >>>> >>>> Axel found a paper describing the task queue algorithm and the >>>> needed ordering on arm and power: >>>> Correct and Efficient Work-Stealing for Weak Memory Models; >>>> L?, Pop, Cohen, Nardelli; PPoPP'13; >>>> http://www.di.ens.fr/~zappa/readings/ppopp13.pdf >>>> >>>> According to this paper we need to add one fence and one load_acquire >>>> to your implementation of the task queue. You find this fence in this small >>>> webrev: http://cr.openjdk.java.net/~goetz/webrevs/8006971-2/ >>>> >>>> With this fence, the algorithm works on Linux for our openjdk ppc >>>> port, and also for our SAP JVM . >>>> >>>> Actually, the fence fixes a problem we discovered with the concurrency >>>> torture test suite. The problem occurs with four or more GC threads. >>>> If three threads are stealing from the queue of the fourth, two of >>>> them can pop the same element. Without a fence between the access >>>> to age and bottom in pop_global(), bottom can be older than age. >>>> >>>> >>>> Unfortunately, the OpenJDK implementation with the added fence >>>> does not work on AIX. Axel already detected one place where the xlC >>>> compiler optimization removed load instruction that is required for >>>> the correctness of the algorithm. If we use our access routines with load_acquire >>>> (see original webrev below) everything works, unclear why. >>>> >>>> Now, we think C++ might allow that this load is removed and xlC does >>>> the correct, but unexpected thing. On the other hand it might also be >>>> a compiler bug. >>>> We are currently discussing this with the IBM xlC developers. >>>> >>>> Best regards, >>>> Axel and Goetz. >>>> >>>> >>>> PS: The webrev we proposed originally: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/ >>>> >>>> >>>> >>>> >>>> >>>> >> From christian.thalinger at oracle.com Wed Mar 20 11:40:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 20 Mar 2013 11:40:57 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <51490F68.10209@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51490F68.10209@oracle.com> Message-ID: <00EFC651-5F18-4FE3-992C-7DED99DDAA14@oracle.com> On Mar 19, 2013, at 6:22 PM, Coleen Phillimore wrote: > > What is the final webrev? I will post a new one in a couple of minutes. > Does this include "hotspot" fix to not use the launcher in the vm repository but still allow debugging with -gdb? No. That will be addressed in a future change. > Does TEST_IN_BUILD go away? Yes, it's gone. -- Chris > thanks, > Coleen > > On 3/19/2013 9:16 PM, Christian Thalinger wrote: >> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >> >>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>> >>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>> >>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>> >>>>>>>> This would be the first of three fixes: >>>>>>>> >>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>> This logic is not suitable: >>>>>>> >>>>>>> 541 # Testing the built JVM >>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>> 544 else >>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>> 546 endif >>>>>>> >>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>> This is so confusing. Our makefiles are an abomination! >>>> I couldn't agree more. >>>> >>>>> So this all started because the makefile has: >>>>> >>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>> >>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>> >>>>> So how did the boot JDK come back into this??? >>>>> >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>> >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>> >>>>>> And here comes this little snippet into play: >>>>>> >>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>> >>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>> >>> ifdef ALT_BOOTDIR >>> >>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>> >>> else >>> >>> ifdef BOOTDIR >>> >>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>> >>> else >>> >>> ifdef JAVA_HOME >>> else >>> >>> endif >>> endif >>> endif >>> >>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >> >> Any reviewers who approve or veto pushing this change? >> >> -- Chris >> >>> This all sucks and needs to be replaced by something completely different. Soon. >>> >>> -- Chris >>> >>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>> >>>> -- Chris >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>> >>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>> >>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> And this addition still makes no sense to me: >>>>>>> >>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>> >>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>> >>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>> >>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>> >>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>> >>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>> running test_gamma. >>>>>>>>>>> >>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>> make/defs.make >>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>> > From christian.tornqvist at oracle.com Wed Mar 20 12:05:14 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 20 Mar 2013 19:05:14 +0000 Subject: hg: hsx/hsx24/hotspot: 8010084: Race in runtime/NMT/BaselineWithParameter.java Message-ID: <20130320190516.A0138482B1@hg.openjdk.java.net> Changeset: 99d14be80708 Author: ctornqvi Date: 2013-03-20 17:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/99d14be80708 8010084: Race in runtime/NMT/BaselineWithParameter.java Summary: Added a waitFor() on the process Reviewed-by: mgerdin, sla, zgu ! test/runtime/NMT/BaselineWithParameter.java From christian.thalinger at oracle.com Wed Mar 20 12:14:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 20 Mar 2013 12:14:38 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <51491C0D.7020906@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> Message-ID: On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: > Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. > > The next looks strange: > > + test_fastdebug: generic_test > + test_fastdebug: VM_FLAVOR=fastdebug > > May be it is time to let Queens go and use -help as you suggested Some data on using -help instead of Queens: - C2 compiles one method when running Queens and two methods for -help - C1 compiles around 44 for Queens and around 20 for -help - tiered compiles 73 for Queens and 33 for -help So it's about the same smoke test for C2 but half for C1. Which is think is enough. None of both do any GC testing. > or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). No, that doesn't work because you need to install the libjvm into a JDK for running that test. Here is a new webrev: http://cr.openjdk.java.net/~twisti/8006965/ (PS: I don't know why udiffs don't work in this webrev.) -- Chris > Vladimir > > On 3/19/13 6:16 PM, Christian Thalinger wrote: >> >> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >> >>> >>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>> >>>> >>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>> >>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>> >>>>>>>> This would be the first of three fixes: >>>>>>>> >>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>> >>>>>>> This logic is not suitable: >>>>>>> >>>>>>> 541 # Testing the built JVM >>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>> 544 else >>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>> 546 endif >>>>>>> >>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>> >>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>> >>>>> This is so confusing. Our makefiles are an abomination! >>>> >>>> I couldn't agree more. >>>> >>>>> >>>>> So this all started because the makefile has: >>>>> >>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>> >>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>> >>>>> So how did the boot JDK come back into this??? >>>>> >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>> >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>> >>>>>> And here comes this little snippet into play: >>>>>> >>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>> >>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>> >>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>> >>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>> >>> ifdef ALT_BOOTDIR >>> >>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>> >>> else >>> >>> ifdef BOOTDIR >>> >>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>> >>> else >>> >>> ifdef JAVA_HOME >>> else >>> >>> endif >>> endif >>> endif >>> >>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >> >> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >> >> Any reviewers who approve or veto pushing this change? >> >> -- Chris >> >>> >>> This all sucks and needs to be replaced by something completely different. Soon. >>> >>> -- Chris >>> >>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>> >>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>> >>>>>>> >>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>> >>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>> >>>>>>> >>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>> >>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> And this addition still makes no sense to me: >>>>>>> >>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>> >>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>> >>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>> >>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>> >>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>> >>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>> >>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>> running test_gamma. >>>>>>>>>>> >>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>> make/defs.make >>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Wed Mar 20 15:12:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Mar 2013 15:12:40 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> Message-ID: <514A3458.3020807@oracle.com> I tested it with my workflow and it produces a lot more output and I did not specify verbose output. It is caused by next change in make/solaris/makefiles/buildtree.make: include $(GAMMADIR)/make/scm.make + include $(GAMMADIR)/make/defs.make include $(GAMMADIR)/make/altsrc.make Why do you need it there? Vladimir On 3/20/13 12:14 PM, Christian Thalinger wrote: > > On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: > >> Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. > > Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. > >> >> The next looks strange: >> >> + test_fastdebug: generic_test >> + test_fastdebug: VM_FLAVOR=fastdebug >> >> May be it is time to let Queens go and use -help as you suggested > > Some data on using -help instead of Queens: > > - C2 compiles one method when running Queens and two methods for -help > - C1 compiles around 44 for Queens and around 20 for -help > - tiered compiles 73 for Queens and 33 for -help > > So it's about the same smoke test for C2 but half for C1. Which is think is enough. > > None of both do any GC testing. > >> or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). > > No, that doesn't work because you need to install the libjvm into a JDK for running that test. > > Here is a new webrev: > > http://cr.openjdk.java.net/~twisti/8006965/ > > (PS: I don't know why udiffs don't work in this webrev.) > > -- Chris > >> Vladimir >> >> On 3/19/13 6:16 PM, Christian Thalinger wrote: >>> >>> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >>> >>>> >>>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>>> >>>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>>> >>>>>>>>> This would be the first of three fixes: >>>>>>>>> >>>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>>> >>>>>>>> This logic is not suitable: >>>>>>>> >>>>>>>> 541 # Testing the built JVM >>>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>> 544 else >>>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>> 546 endif >>>>>>>> >>>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>>> >>>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>>> >>>>>> This is so confusing. Our makefiles are an abomination! >>>>> >>>>> I couldn't agree more. >>>>> >>>>>> >>>>>> So this all started because the makefile has: >>>>>> >>>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>>> >>>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>>> >>>>>> So how did the boot JDK come back into this??? >>>>>> >>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>>> >>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>>> >>>>>>> And here comes this little snippet into play: >>>>>>> >>>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>> >>>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>>> >>>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>>> >>>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>>> >>>> ifdef ALT_BOOTDIR >>>> >>>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>>> >>>> else >>>> >>>> ifdef BOOTDIR >>>> >>>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>>> >>>> else >>>> >>>> ifdef JAVA_HOME >>>> else >>>> >>>> endif >>>> endif >>>> endif >>>> >>>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >>> >>> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >>> >>> Any reviewers who approve or veto pushing this change? >>> >>> -- Chris >>> >>>> >>>> This all sucks and needs to be replaced by something completely different. Soon. >>>> >>>> -- Chris >>>> >>>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>>> >>>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>>> >>>>>>>> >>>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>>> >>>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>>> >>>>>>>> >>>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>>> >>>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> And this addition still makes no sense to me: >>>>>>>> >>>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>> >>>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>>> >>>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>>> >>>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>>> >>>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>>> >>>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>>> running test_gamma. >>>>>>>>>>>> >>>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>>> make/defs.make >>>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> > From John.Coomes at oracle.com Wed Mar 20 15:42:03 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 20 Mar 2013 15:42:03 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> Message-ID: <20810.15163.857570.976967@oracle.com> Christian Thalinger (christian.thalinger at oracle.com) wrote: > > On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: > > > Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. > > Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. I agree, better to avoid it. > > May be it is time to let Queens go and use -help as you suggested > > Some data on using -help instead of Queens: > > - C2 compiles one method when running Queens and two methods for -help > - C1 compiles around 44 for Queens and around 20 for -help > - tiered compiles 73 for Queens and 33 for -help > > So it's about the same smoke test for C2 but half for C1. Which is think is enough. > > None of both do any GC testing. They're doing so little testing that it should be easy to just let them go. But the targets will be useful when we later define a better set of warm-and-breathing tests that are invoked using test/Makefile (even if those require installing the jvm into a jdk, as long as that is automated). > > or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). > > No, that doesn't work because you need to install the libjvm into a JDK for running that test. > > Here is a new webrev: > > http://cr.openjdk.java.net/~twisti/8006965/ This looks good to me. Thanks for persisting. -John > > On 3/19/13 6:16 PM, Christian Thalinger wrote: > >> > >> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: > >> > >>> > >>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > >>> > >>>> > >>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > >>>> > >>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: > >>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: > >>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: > >>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ > >>>>>>>> > >>>>>>>> This would be the first of three fixes: > >>>>>>>> > >>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets > >>>>>>> > >>>>>>> This logic is not suitable: > >>>>>>> > >>>>>>> 541 # Testing the built JVM > >>>>>>> 542 ifeq ($(JAVA_HOME),) > >>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > >>>>>>> 544 else > >>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > >>>>>>> 546 endif > >>>>>>> > >>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! > >>>>>> > >>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: > >>>>> > >>>>> This is so confusing. Our makefiles are an abomination! > >>>> > >>>> I couldn't agree more. > >>>> > >>>>> > >>>>> So this all started because the makefile has: > >>>>> > >>>>> JAVA_HOME=$(ABS_BOOTDIR) > >>>>> > >>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. > >>>>> > >>>>> So how did the boot JDK come back into this??? > >>>>> > >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 > >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > >>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre > >>>>>> > >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo > >>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > >>>>>> JAVA_HOME must point to a 64-bit OpenJDK. > >>>>>> > >>>>>> And here comes this little snippet into play: > >>>>>> > >>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) > >>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > >>>>>> > >>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. > >>>>> > >>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? > >>> > >>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: > >>> > >>> ifdef ALT_BOOTDIR > >>> > >>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac > >>> > >>> else > >>> > >>> ifdef BOOTDIR > >>> > >>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac > >>> > >>> else > >>> > >>> ifdef JAVA_HOME > >>> else > >>> > >>> endif > >>> endif > >>> endif > >>> > >>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). > >> > >> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. > >> > >> Any reviewers who approve or veto pushing this change? > >> > >> -- Chris > >> > >>> > >>> This all sucks and needs to be replaced by something completely different. Soon. > >>> > >>> -- Chris > >>> > >>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? > >>>> > >>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. > >>>> > >>>> -- Chris > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. > >>>>>> > >>>>>>> > >>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? > >>>>>> > >>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. > >>>>>> > >>>>>>> > >>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. > >>>>>> > >>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. > >>>>>> > >>>>>> -- Chris > >>>>>> > >>>>>>> > >>>>>>> And this addition still makes no sense to me: > >>>>>>> > >>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > >>>>>>> > >>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>> > >>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 > >>>>>>>> > >>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} > >>>>>>>> > >>>>>>>> -- Chris > >>>>>>>> > >>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > >>>>>>>>> > >>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. > >>>>>>>>> > >>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? > >>>>>>>>> > >>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. > >>>>>>>>> > >>>>>>>>> -- Chris > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> /Staffan > >>>>>>>>>> > >>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: > >>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 > >>>>>>>>>>> > >>>>>>>>>>> 8006965: test_gamma should run with import JDK > >>>>>>>>>>> Reviewed-by: > >>>>>>>>>>> > >>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where > >>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is > >>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. > >>>>>>>>>>> > >>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when > >>>>>>>>>>> running test_gamma. > >>>>>>>>>>> > >>>>>>>>>>> make/bsd/makefiles/buildtree.make > >>>>>>>>>>> make/defs.make > >>>>>>>>>>> make/linux/makefiles/buildtree.make > >>>>>>>>>>> make/solaris/makefiles/buildtree.make > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>> > >> > From christian.thalinger at oracle.com Wed Mar 20 16:47:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 20 Mar 2013 16:47:48 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <514A3458.3020807@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> <514A3458.3020807@oracle.com> Message-ID: <711B1AF5-78FE-4A70-832A-F34D66F25750@oracle.com> On Mar 20, 2013, at 3:12 PM, Vladimir Kozlov wrote: > I tested it with my workflow and it produces a lot more output and I did not specify verbose output. It is caused by next change in make/solaris/makefiles/buildtree.make: > > include $(GAMMADIR)/make/scm.make > + include $(GAMMADIR)/make/defs.make > include $(GAMMADIR)/make/altsrc.make > > Why do you need it there? Because of JDK_IMPORT_PATH which is now used in buildtree.make. I'm actually surprised that nothing else is required from defs.make. -- Chris > > Vladimir > > On 3/20/13 12:14 PM, Christian Thalinger wrote: >> >> On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: >> >>> Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. >> >> Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. >> >>> >>> The next looks strange: >>> >>> + test_fastdebug: generic_test >>> + test_fastdebug: VM_FLAVOR=fastdebug >>> >>> May be it is time to let Queens go and use -help as you suggested >> >> Some data on using -help instead of Queens: >> >> - C2 compiles one method when running Queens and two methods for -help >> - C1 compiles around 44 for Queens and around 20 for -help >> - tiered compiles 73 for Queens and 33 for -help >> >> So it's about the same smoke test for C2 but half for C1. Which is think is enough. >> >> None of both do any GC testing. >> >>> or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). >> >> No, that doesn't work because you need to install the libjvm into a JDK for running that test. >> >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~twisti/8006965/ >> >> (PS: I don't know why udiffs don't work in this webrev.) >> >> -- Chris >> >>> Vladimir >>> >>> On 3/19/13 6:16 PM, Christian Thalinger wrote: >>>> >>>> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>>>> >>>>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>>>> >>>>>>>>>> This would be the first of three fixes: >>>>>>>>>> >>>>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>>>> >>>>>>>>> This logic is not suitable: >>>>>>>>> >>>>>>>>> 541 # Testing the built JVM >>>>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>> 544 else >>>>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>> 546 endif >>>>>>>>> >>>>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>>>> >>>>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>>>> >>>>>>> This is so confusing. Our makefiles are an abomination! >>>>>> >>>>>> I couldn't agree more. >>>>>> >>>>>>> >>>>>>> So this all started because the makefile has: >>>>>>> >>>>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>>>> >>>>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>>>> >>>>>>> So how did the boot JDK come back into this??? >>>>>>> >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>>>> >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>>>> >>>>>>>> And here comes this little snippet into play: >>>>>>>> >>>>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>> >>>>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>>>> >>>>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>>>> >>>>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>>>> >>>>> ifdef ALT_BOOTDIR >>>>> >>>>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>>>> >>>>> else >>>>> >>>>> ifdef BOOTDIR >>>>> >>>>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>>>> >>>>> else >>>>> >>>>> ifdef JAVA_HOME >>>>> else >>>>> >>>>> endif >>>>> endif >>>>> endif >>>>> >>>>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >>>> >>>> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >>>> >>>> Any reviewers who approve or veto pushing this change? >>>> >>>> -- Chris >>>> >>>>> >>>>> This all sucks and needs to be replaced by something completely different. Soon. >>>>> >>>>> -- Chris >>>>> >>>>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>>>> >>>>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>>>> >>>>>>>>> >>>>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>>>> >>>>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>>>> >>>>>>>>> >>>>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>>>> >>>>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> And this addition still makes no sense to me: >>>>>>>>> >>>>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>>> >>>>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>>>> >>>>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>>>> >>>>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>>>> >>>>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>>>> >>>>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>>>> >>>>>>>>>>> -- Chris >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>>>> >>>>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>> >>>>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>>>> running test_gamma. >>>>>>>>>>>>> >>>>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>>>> make/defs.make >>>>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From christian.thalinger at oracle.com Wed Mar 20 16:56:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 20 Mar 2013 16:56:19 -0700 Subject: 8006965: remove test_gamma and add dedicated test_* targets instead [Was: Re: RFR (S): 8006965: test_gamma should run with import JDK] In-Reply-To: <20810.15163.857570.976967@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> <20810.15163.857570.976967@oracle.com> Message-ID: On Mar 20, 2013, at 3:42 PM, John Coomes wrote: > Christian Thalinger (christian.thalinger at oracle.com) wrote: >> >> On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: >> >>> Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. >> >> Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. > > I agree, better to avoid it. > >>> May be it is time to let Queens go and use -help as you suggested >> >> Some data on using -help instead of Queens: >> >> - C2 compiles one method when running Queens and two methods for -help >> - C1 compiles around 44 for Queens and around 20 for -help >> - tiered compiles 73 for Queens and 33 for -help >> >> So it's about the same smoke test for C2 but half for C1. Which is think is enough. >> >> None of both do any GC testing. > > They're doing so little testing that it should be easy to just let > them go. But the targets will be useful when we later define a better > set of warm-and-breathing tests that are invoked using test/Makefile > (even if those require installing the jvm into a jdk, as long as that > is automated). > >>> or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). >> >> No, that doesn't work because you need to install the libjvm into a JDK for running that test. >> >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~twisti/8006965/ > > This looks good to me. Thanks for persisting. Thank you. By your request I changed the synopsis of the bug: 8006965: remove test_gamma and add dedicated test_* targets instead -- Chris > > -John > >>> On 3/19/13 6:16 PM, Christian Thalinger wrote: >>>> >>>> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>>>> >>>>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>>>> >>>>>>>>>> This would be the first of three fixes: >>>>>>>>>> >>>>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>>>> >>>>>>>>> This logic is not suitable: >>>>>>>>> >>>>>>>>> 541 # Testing the built JVM >>>>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>> 544 else >>>>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>> 546 endif >>>>>>>>> >>>>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>>>> >>>>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>>>> >>>>>>> This is so confusing. Our makefiles are an abomination! >>>>>> >>>>>> I couldn't agree more. >>>>>> >>>>>>> >>>>>>> So this all started because the makefile has: >>>>>>> >>>>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>>>> >>>>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>>>> >>>>>>> So how did the boot JDK come back into this??? >>>>>>> >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>>>> >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>>>> >>>>>>>> And here comes this little snippet into play: >>>>>>>> >>>>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>> >>>>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>>>> >>>>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>>>> >>>>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>>>> >>>>> ifdef ALT_BOOTDIR >>>>> >>>>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>>>> >>>>> else >>>>> >>>>> ifdef BOOTDIR >>>>> >>>>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>>>> >>>>> else >>>>> >>>>> ifdef JAVA_HOME >>>>> else >>>>> >>>>> endif >>>>> endif >>>>> endif >>>>> >>>>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >>>> >>>> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >>>> >>>> Any reviewers who approve or veto pushing this change? >>>> >>>> -- Chris >>>> >>>>> >>>>> This all sucks and needs to be replaced by something completely different. Soon. >>>>> >>>>> -- Chris >>>>> >>>>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>>>> >>>>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>>>> >>>>>>>>> >>>>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>>>> >>>>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>>>> >>>>>>>>> >>>>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>>>> >>>>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> >>>>>>>>> And this addition still makes no sense to me: >>>>>>>>> >>>>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>>> >>>>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>>>> >>>>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>>>> >>>>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>>>> >>>>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>>>> >>>>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>>>> >>>>>>>>>>> -- Chris >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>>>> >>>>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>> >>>>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>>>> running test_gamma. >>>>>>>>>>>>> >>>>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>>>> make/defs.make >>>>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From david.holmes at oracle.com Wed Mar 20 17:15:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Mar 2013 10:15:52 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <711B1AF5-78FE-4A70-832A-F34D66F25750@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> <51491C0D.7020906@oracle.com> <514A3458.3020807@oracle.com> <711B1AF5-78FE-4A70-832A-F34D66F25750@oracle.com> Message-ID: <514A5138.1020704@oracle.com> On 21/03/2013 9:47 AM, Christian Thalinger wrote: > > On Mar 20, 2013, at 3:12 PM, Vladimir Kozlov wrote: > >> I tested it with my workflow and it produces a lot more output and I did not specify verbose output. It is caused by next change in make/solaris/makefiles/buildtree.make: >> >> include $(GAMMADIR)/make/scm.make >> + include $(GAMMADIR)/make/defs.make >> include $(GAMMADIR)/make/altsrc.make >> >> Why do you need it there? > > Because of JDK_IMPORT_PATH which is now used in buildtree.make. I'm actually surprised that nothing else is required from defs.make. We have a complex three tier make system in hotspot. defs.make is supposed to set everything for the top-level make, and update MAKE_ARGS for the submakes (ie buildtree.make invocation); buildtree then outputs hard-wired values into the generated makefiles. In recent time defs.make got added to buildtree.make on linux/bsd. That was not seen to be harmful, but was probably not the right thing to do. The downside is that things in defs.make get executed multiple times - hence the noisy debuginfo stuff. It also means you need to be more careful about what does go into defs.make (values might change depending on which file has included it). JDK_IMPORT_PATH might work okay if just added to MAKE_ARGS in defs.make rather than having to add the include of defs.make in buildtree.make. David ----- > -- Chris > >> >> Vladimir >> >> On 3/20/13 12:14 PM, Christian Thalinger wrote: >>> >>> On Mar 19, 2013, at 7:16 PM, Vladimir Kozlov wrote: >>> >>>> Add new test_* targets to default targets to execute a test when you do 'make all_fastdebug' for example. >>> >>> Yesterday we thought that's a good idea but it's a problem for cross-compilations (e.g. JPRT uses all_* targets). So I'd rather not add test_* targets to all_* targets. >>> >>>> >>>> The next looks strange: >>>> >>>> + test_fastdebug: generic_test >>>> + test_fastdebug: VM_FLAVOR=fastdebug >>>> >>>> May be it is time to let Queens go and use -help as you suggested >>> >>> Some data on using -help instead of Queens: >>> >>> - C2 compiles one method when running Queens and two methods for -help >>> - C1 compiles around 44 for Queens and around 20 for -help >>> - tiered compiles 73 for Queens and 33 for -help >>> >>> So it's about the same smoke test for C2 but half for C1. Which is think is enough. >>> >>> None of both do any GC testing. >>> >>>> or 'cd test; make VM_FLAVOR=$@ servertest' (as JPRT does). >>> >>> No, that doesn't work because you need to install the libjvm into a JDK for running that test. >>> >>> Here is a new webrev: >>> >>> http://cr.openjdk.java.net/~twisti/8006965/ >>> >>> (PS: I don't know why udiffs don't work in this webrev.) >>> >>> -- Chris >>> >>>> Vladimir >>>> >>>> On 3/19/13 6:16 PM, Christian Thalinger wrote: >>>>> >>>>> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >>>>>>> >>>>>>>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>>>>>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>>>>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>>>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>>>>>>> >>>>>>>>>>> This would be the first of three fixes: >>>>>>>>>>> >>>>>>>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>>>>>>> >>>>>>>>>> This logic is not suitable: >>>>>>>>>> >>>>>>>>>> 541 # Testing the built JVM >>>>>>>>>> 542 ifeq ($(JAVA_HOME),) >>>>>>>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>>> 544 else >>>>>>>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>>>>>>> 546 endif >>>>>>>>>> >>>>>>>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>>>>>>> >>>>>>>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>>>>>>> >>>>>>>> This is so confusing. Our makefiles are an abomination! >>>>>>> >>>>>>> I couldn't agree more. >>>>>>> >>>>>>>> >>>>>>>> So this all started because the makefile has: >>>>>>>> >>>>>>>> JAVA_HOME=$(ABS_BOOTDIR) >>>>>>>> >>>>>>>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>>>>>>> >>>>>>>> So how did the boot JDK come back into this??? >>>>>>>> >>>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>>>>>>> >>>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>>>>>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>>>>>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>>>>>>> >>>>>>>>> And here comes this little snippet into play: >>>>>>>>> >>>>>>>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>>>>>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>>> >>>>>>>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>>>>>>> >>>>>>>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? >>>>>> >>>>>> Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: >>>>>> >>>>>> ifdef ALT_BOOTDIR >>>>>> >>>>>> COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac >>>>>> >>>>>> else >>>>>> >>>>>> ifdef BOOTDIR >>>>>> >>>>>> COMPILE.JAVAC = $(BOOTDIR)/bin/javac >>>>>> >>>>>> else >>>>>> >>>>>> ifdef JAVA_HOME >>>>>> else >>>>>> >>>>>> endif >>>>>> endif >>>>>> endif >>>>>> >>>>>> BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). >>>>> >>>>> Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. >>>>> >>>>> Any reviewers who approve or veto pushing this change? >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> This all sucks and needs to be replaced by something completely different. Soon. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >>>>>>> >>>>>>> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>>>>>>> >>>>>>>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>>>>>>> >>>>>>>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> >>>>>>>>>> And this addition still makes no sense to me: >>>>>>>>>> >>>>>>>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>>>>>>> >>>>>>>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>>>>>>> >>>>>>>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>>>>>>> >>>>>>>>>>> -- Chris >>>>>>>>>>> >>>>>>>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>>>>>>> >>>>>>>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>>>>>>> >>>>>>>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>>>>>>> >>>>>>>>>>>> -- Chris >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>>>>>>> running test_gamma. >>>>>>>>>>>>>> >>>>>>>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>>>>>>> make/defs.make >>>>>>>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From daniel.daugherty at oracle.com Wed Mar 20 17:17:33 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 21 Mar 2013 00:17:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130321001753.D5A6B482CB@hg.openjdk.java.net> Changeset: 39432a1cefdd Author: minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author: coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author: zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author: zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author: dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author: sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author: sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/686916dc0439 8009457: SA: A small fix on "scanoops" command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java From erik.helin at oracle.com Thu Mar 21 11:04:35 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 21 Mar 2013 18:04:35 +0000 Subject: hg: hsx/hsx24/hotspot: 8010289: PSParallelCompact::marking_phase should use instance GCTracer Message-ID: <20130321180443.697C4482F1@hg.openjdk.java.net> Changeset: 5bcfc2ed94a5 Author: ehelin Date: 2013-03-19 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5bcfc2ed94a5 8010289: PSParallelCompact::marking_phase should use instance GCTracer Reviewed-by: johnc, mgerdin, stefank ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp From alejandro.murillo at oracle.com Thu Mar 21 17:08:43 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 22 Mar 2013 00:08:43 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130322000852.074E748303@hg.openjdk.java.net> Changeset: 06db2de2922a Author: katleman Date: 2013-03-20 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/06db2de2922a Added tag jdk7u14-b17 for changeset 61822da2b149 ! .hgtags Changeset: c5c01d4cd7d9 Author: amurillo Date: 2013-03-21 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c5c01d4cd7d9 Merge Changeset: 72e4bc0bcbd2 Author: amurillo Date: 2013-03-21 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/72e4bc0bcbd2 Added tag hs24-b37 for changeset c5c01d4cd7d9 ! .hgtags From john.coomes at oracle.com Thu Mar 21 20:37:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 03:37:19 +0000 Subject: hg: hsx/hotspot-main/corba: 14 new changesets Message-ID: <20130322033912.A0B6748309@hg.openjdk.java.net> Changeset: 0ac9424678e7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0ac9424678e7 Added tag jdk8-b81 for changeset 2a00aeeb466b ! .hgtags Changeset: e725dd195858 Author: dmeetry Date: 2013-02-15 01:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e725dd195858 7199858: Marshal exception is wrong Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java Changeset: c528d8ce83f1 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/c528d8ce83f1 Merge Changeset: 67ef27b4e16c Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/67ef27b4e16c Merge Changeset: 05386b4610e9 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/05386b4610e9 Merge Changeset: 3c73273667ae Author: coffeys Date: 2012-10-30 17:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/3c73273667ae 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 80882eae6279 Author: ngmr Date: 2012-10-30 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/80882eae6279 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 0ca1fc7c5f44 Author: mbankal Date: 2012-12-17 07:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0ca1fc7c5f44 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: f4f39d873b9a Author: coffeys Date: 2012-11-06 15:50 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/f4f39d873b9a 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 59bff16bc0bf Author: ewendeli Date: 2013-02-19 21:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/59bff16bc0bf Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 996bd5fd0941 Author: ewendeli Date: 2013-02-25 07:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/996bd5fd0941 Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 7341134e52ff Author: lana Date: 2013-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/7341134e52ff Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 48e1bc77004d Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/48e1bc77004d Merge Changeset: a45bb25a67c7 Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags From john.coomes at oracle.com Thu Mar 21 20:39:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 03:39:34 +0000 Subject: hg: hsx/hotspot-main/jaxp: 7 new changesets Message-ID: <20130322034207.661A14830A@hg.openjdk.java.net> Changeset: 94000590f01f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/94000590f01f Added tag jdk8-b81 for changeset ef3495555a4c ! .hgtags Changeset: f4898ff0aff1 Author: joehw Date: 2012-12-12 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f4898ff0aff1 8001235: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java Changeset: 3206516132e8 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/3206516132e8 Merge Changeset: 46ce56a4e40f Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/46ce56a4e40f Merge Changeset: 8a0cb78fefbc Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8a0cb78fefbc Merge Changeset: d5a58291f09a Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d5a58291f09a Merge Changeset: a46d69a1a8ec Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a46d69a1a8ec Added tag jdk8-b82 for changeset d5a58291f09a ! .hgtags From john.coomes at oracle.com Thu Mar 21 20:42:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 03:42:26 +0000 Subject: hg: hsx/hotspot-main/jaxws: 2 new changesets Message-ID: <20130322034307.23ACA4830B@hg.openjdk.java.net> Changeset: d8d8032d02d7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d8d8032d02d7 Added tag jdk8-b81 for changeset c88bb21560cc ! .hgtags Changeset: a1dcc0d83da1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/a1dcc0d83da1 Added tag jdk8-b82 for changeset d8d8032d02d7 ! .hgtags From john.coomes at oracle.com Thu Mar 21 21:06:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 04:06:56 +0000 Subject: hg: hsx/hotspot-main/jdk: 170 new changesets Message-ID: <20130322044627.C93E548310@hg.openjdk.java.net> Changeset: aee1c6c52b68 Author: erikj Date: 2013-03-06 16:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aee1c6c52b68 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk Changeset: da8edcfc19af Author: katleman Date: 2013-03-11 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da8edcfc19af Merge Changeset: bc0ca8bc4637 Author: erikj Date: 2013-03-12 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc0ca8bc4637 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine Reviewed-by: dholmes, tbell ! make/common/shared/Defs-utils.gmk ! makefiles/Images.gmk Changeset: c0f8022eba53 Author: katleman Date: 2013-03-12 19:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c0f8022eba53 Merge Changeset: 509c45748f3e Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/509c45748f3e Added tag jdk8-b81 for changeset c0f8022eba53 ! .hgtags Changeset: f6eb212081b2 Author: jgodinez Date: 2013-02-14 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f6eb212081b2 8008173: [parfait] #1173 Uninitialised variable -- TransformHelper.cpp Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 4b11045a9c4c Author: jgodinez Date: 2013-02-18 14:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b11045a9c4c 8005191: [parfait] #384 sun/font/layout/LookupProcessor.cpp Null pointer dereference Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: 41008f5cef1a Author: lana Date: 2013-02-19 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41008f5cef1a Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: d2d7da120c37 Author: jgodinez Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d2d7da120c37 8006110: pageDialog is showing the swing dialog with DialogTypeSelection.NATIVE Reviewed-by: bae, prr ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 99c1f910abcc Author: jgodinez Date: 2013-02-22 13:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99c1f910abcc 8005796: [parfait] Possible uninitialised variable at jdk/src/share/native/sun/java2d/loops/ByteBinary1Bit.c Reviewed-by: prr, vadim, flar Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h Changeset: 934f5f10107d Author: lana Date: 2013-02-22 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/934f5f10107d Merge Changeset: 4fd6048a78c0 Author: lana Date: 2013-02-22 23:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4fd6048a78c0 Merge Changeset: f3368a3fc023 Author: bae Date: 2013-03-05 17:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3368a3fc023 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Reviewed-by: jgodinez, ant ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/native/sun/font/AWTStrike.m Changeset: fd8810d50c99 Author: bae Date: 2013-03-07 14:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd8810d50c99 8005530: [lcms] Improve performance of ColorConverOp for default destinations Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/Makefile ! make/sun/cmm/lcms/mapfile-vers ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/liblcms/mapfile-vers ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/demo/java2d/J2DBench/build.xml + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_medium.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_small.jpg ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 8e9b133dcec9 Author: lana Date: 2013-03-12 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e9b133dcec9 Merge Changeset: e6c94a202bfd Author: alexsch Date: 2013-02-15 14:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6c94a202bfd 7173873: JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) will never lead to SE if EXIT_ON_CLOSE is already set Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/JFrame.java Changeset: 4bf242def958 Author: dingxmin Date: 2013-02-15 15:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bf242def958 8008289: DefaultButtonModel instance keeps stale listeners in html FormView Reviewed-by: malenkov, alexsch ! src/share/classes/javax/swing/text/html/FormView.java + test/javax/swing/text/html/7189299/bug7189299.java Changeset: 88a83b9e9baa Author: kshefov Date: 2013-02-15 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88a83b9e9baa 8005920: After pressing combination Windows Key and M key, the frame, the instruction and the dialog can't be minimized. Reviewed-by: serb, denis Contributed-by: Vera Akulova ! test/java/awt/Modal/WsDisabledStyle/Winkey/Winkey.java Changeset: 0fe12ecf80b2 Author: pchelko Date: 2013-02-19 11:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0fe12ecf80b2 8008374: Build failure (NEWBUILD=false) on Mac Summary: Fixed an old build system failure Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: 5ad0bd367f6d Author: kshefov Date: 2013-02-19 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ad0bd367f6d 8008379: TEST_BUG: Fail automatically with java.lang.NullPointerException. Reviewed-by: serb, anthony + test/java/awt/Modal/ModalDialogMultiscreenTest/ModalDialogMultiscreenTest.java Changeset: a43115c6359d Author: kshefov Date: 2013-02-19 20:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a43115c6359d 8006070: TEST_BUG: Up and down the Y coordinate of the mouse position, the selected item doesn't change for the single list. Reviewed-by: serb, anthony + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java Changeset: 9bc26b7b8b47 Author: lana Date: 2013-02-19 22:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bc26b7b8b47 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 73d1efc4710a Author: ant Date: 2013-02-22 15:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/73d1efc4710a 8006406: lightweight embedding in other Java UI toolkits Reviewed-by: serb, anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HToolkit.java + src/share/classes/sun/awt/LightweightFrame.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/swing/JLightweightFrame.java + src/share/classes/sun/swing/LightweightContent.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java + src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Window.h Changeset: 63bb402d4a6a Author: lana Date: 2013-02-23 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/63bb402d4a6a Merge Changeset: d502cc7bcc3d Author: pchelko Date: 2013-02-25 10:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d502cc7bcc3d 8006634: Unify LWCToolkit.invokeAndWait() and sun.awt.datatransfer.ToolkitThreadBlockedHandler Summary: Changed the logic for the nested event loops and deleted deadlock detection Reviewed-by: art, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e58f0b163f43 Author: denis Date: 2013-02-27 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e58f0b163f43 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: bc914b7f0878 Author: denis Date: 2013-02-27 20:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc914b7f0878 8009158: Incomplete fix for 7178079 Reviewed-by: serb, anthony ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: 3dee850e2653 Author: serb Date: 2013-02-28 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3dee850e2653 8008660: Failure in 2D Queue Flusher thread on Mac Reviewed-by: swingler, bae ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: 554d0f41a6ab Author: serb Date: 2013-02-28 20:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/554d0f41a6ab 8003169: [macosx] JVM crash after disconnecting from projector Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 657a02fcaa00 Author: malenkov Date: 2013-03-01 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/657a02fcaa00 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch ! src/share/classes/java/beans/PropertyDescriptor.java ! test/java/beans/Introspector/Test7192955.java Changeset: 5816595a4cdc Author: serb Date: 2013-03-01 15:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5816595a4cdc 7194902: [macosx] closed/java/awt/Button/DoubleActionEventTest/DoubleActionEventTest failed since jdk8b49 7181403: Invalid MouseEvent conversion with SwingUtilities.convertMouseEvent Reviewed-by: malenkov, alexsch ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 4912a9e3a95e Author: serb Date: 2013-03-01 21:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4912a9e3a95e 7184945: [macosx] NPE in AquaComboBoxUI since jdk7u6b17, jdk8b47 Reviewed-by: malenkov, alexsch ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: 91e17a813483 Author: alexsch Date: 2013-03-06 19:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/91e17a813483 6877495: JTextField and JTextArea does not support supplementary characters Reviewed-by: serb, alexp ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 7962014b1729 Author: mcherkas Date: 2013-03-06 20:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7962014b1729 8007295: Reduce number of warnings in awt classes Reviewed-by: bae, anthony ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/geom/AffineTransform.java Changeset: f3ffead3069e Author: lana Date: 2013-03-12 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3ffead3069e Merge Changeset: 153884b550f0 Author: chegar Date: 2013-02-14 13:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/153884b550f0 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Reviewed-by: mcimadamore ! test/ProblemList.txt Changeset: e57019d2f34a Author: mduigou Date: 2013-02-13 14:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e57019d2f34a 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up Reviewed-by: mduigou, martin Contributed-by: Peter Levart ! src/share/classes/java/util/IdentityHashMap.java Changeset: 1405ad6afb1e Author: bharadwaj Date: 2013-02-14 11:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1405ad6afb1e 8007736: VerifyError for use of static method in interface Reviewed-by: mchung ! src/share/native/common/check_code.c + test/vm/verifier/TestStaticIF.java Changeset: 1ce1a307cded Author: sherman Date: 2013-02-15 01:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ce1a307cded 8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing Summary: to use j.t.ZoneId zone name to keep round-trip Reviewed-by: okutsu ! test/java/util/Calendar/JavatimeTest.java Changeset: 048637b40787 Author: chegar Date: 2013-02-15 11:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/048637b40787 8008223: java/net/BindException/Test.java fails rarely Reviewed-by: khazra, alanb ! test/java/net/BindException/Test.java Changeset: 7748ffdca16a Author: rfield Date: 2013-02-16 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7748ffdca16a 8004970: Implement serialization in the lambda metafactory Reviewed-by: forax ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java + src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 43726ed11fb3 Author: sherman Date: 2013-02-17 01:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43726ed11fb3 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control Summary: To remove jdk/make/tools/javazic from the jdk repo Reviewed-by: alanb - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: ce6a2fcb4c9b Author: yhuang Date: 2013-02-16 21:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce6a2fcb4c9b 8006748: getISO3Country() returns wrong value Reviewed-by: naoto ! src/share/classes/java/util/LocaleISOData.java Changeset: bcde0486261e Author: dingxmin Date: 2013-02-18 08:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bcde0486261e 6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/RacyDeregister.java Changeset: 49b3d8efd30a Author: darcy Date: 2013-02-19 00:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/49b3d8efd30a 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Reviewed-by: mduigou, okutsu ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/util/TimeZone.java Changeset: 885bb24f6018 Author: coffeys Date: 2013-02-19 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author: coffeys Date: 2013-02-19 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java Changeset: 824187de1591 Author: jzavgren Date: 2013-02-19 16:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/824187de1591 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Reviewed-by: alanb, chegar, dholmes ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: e20c1c9197bf Author: emc Date: 2013-02-19 17:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e20c1c9197bf 8008312: Re-enable MethodParameter tests in JDK Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java Changeset: af396ec087f4 Author: naoto Date: 2013-02-19 10:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af396ec087f4 7092447: Clarify the default locale used in each locale sensitive operation Reviewed-by: okutsu ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Scanner.java Changeset: 16efb7ba188f Author: mduigou Date: 2013-02-19 11:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/16efb7ba188f 8004561: Additional functional interfaces, extension methods and name changes Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions. Reviewed-by: briangoetz, darcy, chegar, dholmes ! src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java + src/share/classes/java/util/function/BiConsumer.java + src/share/classes/java/util/function/BiFunction.java + src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/BooleanSupplier.java + src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java - src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java - src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java - src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/ObjDoubleConsumer.java + src/share/classes/java/util/function/ObjIntConsumer.java + src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/ToDoubleBiFunction.java + src/share/classes/java/util/function/ToDoubleFunction.java + src/share/classes/java/util/function/ToIntBiFunction.java + src/share/classes/java/util/function/ToIntFunction.java + src/share/classes/java/util/function/ToLongBiFunction.java + src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java ! test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 267bca6af07e Author: jzavgren Date: 2013-02-19 15:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/267bca6af07e 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Reviewed-by: mullan, chegar ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: ec1a79c3a99c Author: ksrini Date: 2013-02-19 16:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ec1a79c3a99c 8008262: pack200 should support MethodParameters - part 2 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/Utils.java Changeset: 85a44860f5bb Author: lana Date: 2013-02-19 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85a44860f5bb Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: ca43e2761a1d Author: ykantser Date: 2013-02-13 10:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca43e2761a1d 8008089: Delete OS dependent check in JdkFinder.getExecutable() Reviewed-by: egahlin, alanb ! test/lib/testlibrary/jdk/testlibrary/JdkFinder.java Changeset: 0a2b308cc82d Author: uta Date: 2013-02-20 16:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a2b308cc82d 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Summary: the SetHandleInformation arguments list was fixed. Reviewed-by: alanb ! src/windows/native/java/lang/ProcessImpl_md.c Changeset: 5772e9edbc4c Author: dcubed Date: 2013-02-20 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5772e9edbc4c 8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS Summary: Use more portable pattern counting constructs in test driver. Reviewed-by: sspitsyn, sla, coleenp ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh Changeset: 1da987f0311a Author: rfield Date: 2013-02-21 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1da987f0311a 8008356: Test LambdaSerialization.java failing Summary: run in /othervm mode Reviewed-by: ksrini ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 03db11a7fb8e Author: lana Date: 2013-02-21 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/03db11a7fb8e Merge Changeset: 9078c34437ab Author: msheppar Date: 2013-02-21 20:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9078c34437ab 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder Reviewed-by: vinnie, chegar, sherman ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java Changeset: c6d77b2b4478 Author: stefank Date: 2013-01-22 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6d77b2b4478 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodInBacktrace.sh + test/java/lang/instrument/RedefineMethodInBacktraceAgent.java + test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java Changeset: 0e93015e77f6 Author: stefank Date: 2013-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e93015e77f6 7140852: Add test for 7022100 Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodWithAnnotations.sh + test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java + test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java + test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java Changeset: 63fe6a9820b6 Author: alanb Date: 2013-02-22 14:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/63fe6a9820b6 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Reviewed-by: lancea, chegar, iris, mchung, sherman ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 9f9dac5a9e74 Author: lancea Date: 2013-02-22 09:29 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f9dac5a9e74 8008716: address typo in CallableStatement javadocs Reviewed-by: chegar ! src/share/classes/java/sql/CallableStatement.java Changeset: 8d8a35ac7d40 Author: lancea Date: 2013-02-22 09:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d8a35ac7d40 Merge Changeset: 6f9b3e216b01 Author: darcy Date: 2013-02-23 13:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f9b3e216b01 6556996: (ann spec) SuppressWarnings strings should be documented Reviewed-by: mduigou, chegar, abuckley ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/SafeVarargs.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/Inherited.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java Changeset: 155095c245b4 Author: alanb Date: 2013-02-25 17:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/155095c245b4 8008808: Allowed dependencies added by JDK-8008481 no longer required Reviewed-by: tbell, chegar ! make/tools/src/build/tools/deps/refs.allowed Changeset: 58f829566fe3 Author: bchristi Date: 2013-02-25 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58f829566fe3 8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Summary: Avoid automated test failure by just exiting when in 'C' locale Reviewed-by: naoto, ksrini ! test/ProblemList.txt ! test/tools/launcher/I18NJarTest.java Changeset: 4cf4403c9bf2 Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4cf4403c9bf2 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: bc92e4b044e2 Author: kmo Date: 2013-02-26 11:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc92e4b044e2 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/7087570/Test7087570.java Changeset: 5fcecbcefb71 Author: chegar Date: 2013-02-26 11:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5fcecbcefb71 Merge Changeset: 77447981db73 Author: chegar Date: 2013-02-26 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77447981db73 Merge Changeset: 022cd5adc0fa Author: alanb Date: 2013-02-26 14:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/022cd5adc0fa 8008977: profiles build broken by Nashorn build changes Reviewed-by: chegar ! makefiles/profile-rtjar-includes.txt Changeset: 5ebc62421717 Author: rfield Date: 2013-02-26 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ebc62421717 8008770: SerializedLambda incorrect class loader for lambda deserializing class Summary: current thread's context ClassLoader was used to load class by name, pass class not name in serialization (Thank you Peter Levart for test and prototype. Thank you Sundar and Peter for unofficial reviews) Reviewed-by: forax ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java + test/java/lang/invoke/lambda/LambdaClassLoaderSerialization.java ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: ecd33c6ab12f Author: alanb Date: 2013-02-26 22:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ecd33c6ab12f 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Reviewed-by: mduigou ! makefiles/CreateJars.gmk Changeset: 543be9488e50 Author: darcy Date: 2013-02-26 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/543be9488e50 8009102: Several docs warnings in Project Lambda APIs Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java Changeset: d623f520557b Author: darcy Date: 2013-02-26 17:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d623f520557b 8008279: Remove InvalidContainerAnnotationError.java Reviewed-by: jfranck - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: f5416026cdf5 Author: sundar Date: 2013-02-27 17:22 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f5416026cdf5 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java + test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java - test/javax/script/RhinoExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test3.js ! test/javax/script/Test5.java ! test/javax/script/Test5.js ! test/javax/script/Test6.java ! test/javax/script/Test7.js ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java Changeset: 13013dedcdfd Author: alanb Date: 2013-02-27 14:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13013dedcdfd 8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present Reviewed-by: hawtin, mullan, dsamersoff, mchung ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/security/util/SecurityConstants.java ! test/java/lang/SecurityManager/NoAWT.java Changeset: 1b3173c326e6 Author: sundar Date: 2013-02-27 20:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b3173c326e6 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Reviewed-by: alanb ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/jrunscript/repl.out Changeset: 093fdf8937bd Author: vladidan Date: 2013-02-22 17:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/093fdf8937bd 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Summary: Adding sun.os.abi Java Property support Reviewed-by: bobv, alanb, dholmes ! makefiles/Images.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c Changeset: f4b01f4e8f35 Author: mduigou Date: 2013-02-27 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4b01f4e8f35 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 Reviewed-by: alanb ! src/share/classes/java/util/IdentityHashMap.java + test/java/util/Map/ToArray.java Changeset: 7d272e524768 Author: chegar Date: 2013-02-28 12:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d272e524768 8006409: ThreadLocalRandom should dropping padding fields from its serialized form Reviewed-by: dl, martin, alanb, shade ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 7246a6e4dd5a Author: juh Date: 2013-02-28 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7246a6e4dd5a 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ca712765acb Merge Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/ThreadLessCommon.java + test/java/util/concurrent/forkjoin/ThrowingRunnable.java Changeset: df76ba760eec Author: ksrini Date: 2013-03-03 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df76ba760eec 8007297: [pack200] allow opcodes with InterfaceMethodRefs Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java Changeset: 83e847f59fd6 Author: darcy Date: 2013-03-04 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83e847f59fd6 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Reviewed-by: jjg ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/OldenCompilingWithDefaults.java Changeset: 1a2e59d19d3e Author: naoto Date: 2013-03-04 20:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a2e59d19d3e 8004240: Return value from getAdapterPrefence() can be modified Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + test/java/util/Locale/Bug8004240.java Changeset: 62639ca66ab9 Author: ewang Date: 2013-03-05 10:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62639ca66ab9 8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Reviewed-by: chegar, alanb ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/Cleaner/exitOnThrow.sh Changeset: b5bef1f71de6 Author: jzavgren Date: 2013-03-05 14:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b5bef1f71de6 8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c Reviewed-by: alanb, chegar, dsamersoff ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Changeset: be79440b8026 Author: jzavgren Date: 2013-03-05 09:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be79440b8026 4880778: URL final class has protected methods Summary: The two set() methods have been defined to be package private. Reviewed-by: alanb, chegar, khazra ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java Changeset: f960a34f05ce Author: lana Date: 2013-03-05 11:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f960a34f05ce Merge ! makefiles/Images.gmk Changeset: 34372bb9115d Author: sla Date: 2013-03-05 19:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/34372bb9115d 8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Reviewed-by: alanb ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: 38e1821c4472 Author: jfranck Date: 2013-03-06 18:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/38e1821c4472 8007808: Missing method: Executable.getAnnotatedReturnType() Reviewed-by: darcy, forax ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java Changeset: 14e49a70729a Author: martin Date: 2013-03-06 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/14e49a70729a 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Summary: Define FILES_m to force use of linker script Reviewed-by: sherman, alanb, ohair ! make/java/zip/Makefile ! src/share/native/java/util/zip/Inflater.c Changeset: cf54f6be3e9e Author: weijun Date: 2013-03-07 11:32 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf54f6be3e9e 8009604: old make images failed: JarBASE64Encoder class not found Reviewed-by: xuelei, wetmore ! make/common/Release.gmk Changeset: 48b7295f02f8 Author: chegar Date: 2013-03-07 10:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/48b7295f02f8 6370908: Add support for HTTP_CONNECT proxy in Socket class Reviewed-by: chegar Contributed-by: Damjan Jovanovic , Chris Hegarty + src/share/classes/java/net/HttpConnectSocketImpl.java ! src/share/classes/java/net/Socket.java + test/java/net/Socket/HttpProxy.java Changeset: 98cf76df3e6e Author: alanb Date: 2013-03-08 12:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98cf76df3e6e 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Reviewed-by: chegar + test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: 01908630df14 Author: alanb Date: 2013-03-08 19:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01908630df14 8009645: ClassFileTransformer hooks in ClassLoader no longer required Reviewed-by: mchung, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/ClassFileTransformer.java Changeset: e38b46041049 Author: mduigou Date: 2013-03-08 15:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e38b46041049 8001667: Comparator combinators and extension methods Reviewed-by: mduigou, briangoetz Contributed-by: henry.jen at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java + src/share/classes/java/util/Comparators.java ! test/java/util/Collections/ReverseOrder.java + test/java/util/ComparatorsTest.java Changeset: 230bafd05509 Author: weijun Date: 2013-03-09 17:27 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/230bafd05509 8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid) Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/SpnegoLifeTime.java Changeset: 334ddf3b101f Author: coleenp Date: 2013-03-12 10:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/334ddf3b101f 7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions. Summary: Do not check that the padding bytes are zero if class file format version >=51. Reviewed-by: dholmes, coleenp, mullan, kvn Contributed-by: harold.seigel at oracle.com ! src/share/native/common/check_code.c Changeset: 6379415d8fca Author: wetmore Date: 2013-03-12 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6379415d8fca 8009925: Back out AEAD CipherSuites temporarily Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java - test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 5880bfd30db1 Author: lana Date: 2013-03-12 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5880bfd30db1 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - test/javax/script/RhinoExceptionTest.java Changeset: 72ffb2bc15bb Author: lana Date: 2013-03-12 18:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72ffb2bc15bb Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java ! test/ProblemList.txt - test/javax/script/RhinoExceptionTest.java Changeset: 66a892bb28b7 Author: anthony Date: 2012-10-12 15:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/66a892bb28b7 7173145: Improve in-memory representation of splashscreens Reviewed-by: bae, mschoene ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 85bf51db473c Author: xuelei Date: 2012-10-15 07:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85bf51db473c 7192393: Better Checking of order of TLS Messages Summary: Also reviewed by Andrew Gross Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 24a3eb2f0553 Author: malenkov Date: 2012-10-15 19:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/24a3eb2f0553 7200493: Improve cache handling Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/finder/MethodFinder.java Changeset: c7c39320bc6c Author: rupashka Date: 2012-10-16 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c7c39320bc6c 7186948: Improve Swing data validation Reviewed-by: art, ahgross ! src/share/classes/javax/swing/UIDefaults.java Changeset: 3c8d0085b094 Author: ksrini Date: 2012-10-16 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c8d0085b094 7186945: Unpack200 improvement Reviewed-by: jrose, jjh, mschoene ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 01f67953c057 Author: ksrini Date: 2012-10-16 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01f67953c057 7186957: Improve Pack200 data validation Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: b0bf41ba1cf8 Author: ksrini Date: 2012-10-16 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0bf41ba1cf8 7186946: Refine unpacker resource usage Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: f0bc5a6dff2b Author: ksrini Date: 2012-10-16 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0bc5a6dff2b 7200499: Better data validation for options Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c Changeset: 7e19ab4ff5d3 Author: ksrini Date: 2012-10-16 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e19ab4ff5d3 7200500: Launcher better input validation Reviewed-by: darcy, jjh, mschoene ! src/share/bin/parse_manifest.c Changeset: 62f3270f03fa Author: dholmes Date: 2012-08-22 21:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62f3270f03fa 6776941: Improve thread pool shutdown Reviewed-by: dl, skoivu ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: e7cce63bf293 Author: xuelei Date: 2012-10-22 07:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7cce63bf293 7192392: Better validation of client keys Summary: Also reviewed by Andrew Gross Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java - src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/KeyUtil.java ! test/sun/security/mscapi/ShortRSAKeyWithinTLS.java Changeset: 091dd6eb30aa Author: khazra Date: 2012-10-22 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/091dd6eb30aa 7186954: Improve connection performance Reviewed-by: chegar, skoivu ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java Changeset: c26d42a92bd8 Author: weijun Date: 2012-09-19 12:58 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c26d42a92bd8 8000210: Improve JarFile code quality Reviewed-by: ahgross, xuelei, mschoene ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java Changeset: a54b61ae6f12 Author: mullan Date: 2012-10-26 15:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a54b61ae6f12 7201068: Better handling of UI elements Reviewed-by: xuelei ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 71ab8d79c6b4 Author: asaha Date: 2012-10-26 10:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71ab8d79c6b4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: be07910b3fad Author: asaha Date: 2012-10-26 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be07910b3fad Merge Changeset: e14221289076 Author: dsamersoff Date: 2012-10-30 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e14221289076 8000539: JMX implementation allows invocation of methods of a system class Summary: Added extra packageAccess check call Reviewed-by: ahgross, dfuchs Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 64440cc2ea8b Author: mchung Date: 2012-11-02 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64440cc2ea8b 7197546: (proxy) Reflect about creating reflective proxies Reviewed-by: alanb, jdn, jrose ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy Changeset: f936be5be1e7 Author: rupashka Date: 2012-11-06 15:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f936be5be1e7 7200491: Tighten up JTable layout code Reviewed-by: art, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java Changeset: 3069b91ff041 Author: chegar Date: 2012-11-07 14:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3069b91ff041 7201071: InetSocketAddress serialization issue Reviewed-by: alanb, michaelm, skoivu ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java Changeset: 69fd15e0437d Author: smarks Date: 2012-11-08 15:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69fd15e0437d 7201070: Serialization to conform to protocol Reviewed-by: dmocek, ahgross, skoivu ! src/share/classes/java/io/ObjectInputStream.java Changeset: 9097b6ec0ecd Author: ksrini Date: 2012-11-09 14:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9097b6ec0ecd 8002091: tools/launcher/ToolsOpts.java test started to fail since 7u11 b01 on Windows Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c ! test/tools/launcher/ToolsOpts.java Changeset: 7bc8d5a63d9e Author: bagiras Date: 2012-11-15 23:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bc8d5a63d9e 7192977: Issue in toolkit thread Reviewed-by: skoivu, rupashka, art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 09e2dcd476cf Author: bae Date: 2012-11-16 11:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09e2dcd476cf 8001972: Improve image processing Reviewed-by: prr, ahgross ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 1b616e1ca09c Author: dmocek Date: 2012-11-19 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b616e1ca09c 6563318: RMI data sanitization Reviewed-by: ahgross, hawtin, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! test/java/rmi/testlibrary/JavaVM.java Changeset: aa8717a5c9cd Author: dmocek Date: 2012-11-19 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aa8717a5c9cd 8001242: Improve RMI HTTP conformance Reviewed-by: ahgross, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java Changeset: ecedf46ae7db Author: bae Date: 2012-11-20 11:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ecedf46ae7db 8002325: Improve management of images Reviewed-by: prr, ahgross ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h Changeset: eda84d5738e3 Author: denis Date: 2012-11-26 20:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eda84d5738e3 7186952: Improve clipboard access Reviewed-by: serb, ahgross ! src/share/classes/java/awt/TextComponent.java ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: d1668eca22bf Author: mchung Date: 2012-11-26 22:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d1668eca22bf 6664509: Add logging context 6664528: Find log level matching its name or value given at construction time Reviewed-by: alanb, ahgross, jgish, hawtin ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/lib/security/java.security Changeset: b8ee2e9ff7e3 Author: denis Date: 2012-11-30 15:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8ee2e9ff7e3 7201064: Better dialogue checking Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: 90bbdae7aaa4 Author: ewendeli Date: 2013-02-03 23:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90bbdae7aaa4 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/rmi/testlibrary/JavaVM.java Changeset: cc2057f84eb7 Author: mchung Date: 2012-12-05 14:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc2057f84eb7 8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows} Reviewed-by: alanb, ahgross, mullan ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89e43b8940c9 Author: dsamersoff Date: 2012-12-07 22:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89e43b8940c9 8000537: Contextualize RequiredModelMBean class Summary: Contextualize RequiredModelMBean class Reviewed-by: asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: 7933c80c162a Author: denis Date: 2012-12-12 21:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7933c80c162a 8004341: Two JCK tests fails with 7u11 b06 Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: ed08394e1a15 Author: mullan Date: 2012-12-18 13:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ed08394e1a15 8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01 Reviewed-by: vinnie, skoivu, mgrebac, ohair, tbell ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 32cd4975d2d6 Author: mchung Date: 2013-01-10 19:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/32cd4975d2d6 8005615: Java Logger fails to load tomcat logger implementation (JULI) Reviewed-by: alanb, ahgross ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/CustomLogManager.java + test/java/util/logging/CustomLogManagerTest.java + test/java/util/logging/SimpleLogManager.java Changeset: c0fbd737aef0 Author: ewendeli Date: 2013-01-28 11:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c0fbd737aef0 8006864: Update java.security-linux to include changes in java.security Reviewed-by: mchung, mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 12491fa16985 Author: ewendeli Date: 2013-02-05 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12491fa16985 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java Changeset: de419ea8ed8f Author: mchung Date: 2013-01-28 15:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de419ea8ed8f 8006882: Proxy generated classes in sun.proxy package breaks JMockit Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8effe3b7489d Author: dfuchs Date: 2013-01-30 11:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8effe3b7489d 8006446: Restrict MBeanServer access Reviewed-by: alanb, mchung, darcy, jrose, ahgross, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java Changeset: ebfb0bb58428 Author: mchung Date: 2013-01-24 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ebfb0bb58428 8004937: Improve proxy construction Reviewed-by: jrose, ahgross ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java Changeset: af11c227a91e Author: mchung Date: 2013-02-05 22:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af11c227a91e 8007393: Possible race condition after JDK-6664509 Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 1143bb5e7064 Author: mchung Date: 2013-02-07 09:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1143bb5e7064 8007611: logging behavior in applet changed Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 5925630b7a7d Author: xuelei Date: 2013-02-07 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5925630b7a7d 8006777: Improve TLS handling of invalid messages Reviewed-by: wetmore, ahgross ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: d57363ff612f Author: valeriep Date: 2013-02-07 16:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d57363ff612f 8007688: Blacklist known bad certificate Summary: Added two known bad certs to the blacklist certs. Reviewed-by: mullan ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: c18aeb4ca957 Author: ewendeli Date: 2013-02-19 21:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c18aeb4ca957 Merge ! src/share/bin/parse_manifest.c ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/sun/awt/image/awt_parseImage.c ! test/Makefile Changeset: f7fb3de623ba Author: ewendeli Date: 2013-02-19 21:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7fb3de623ba Merge Changeset: f686c8e3c8e0 Author: ewendeli Date: 2013-02-25 08:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f686c8e3c8e0 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: e3cac5962e32 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3cac5962e32 8006439: Improve MethodHandles coverage Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 62be74f35886 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62be74f35886 8006179: JSR292 MethodHandles lookup with interface using findVirtual() Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java Changeset: 9995881dfb4e Author: vlivanov Date: 2013-02-22 02:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9995881dfb4e 8006125: Update MethodHandles library interactions Reviewed-by: jrose ! src/share/classes/sun/reflect/misc/MethodUtil.java Changeset: 0807820fca96 Author: vlivanov Date: 2013-02-22 02:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0807820fca96 8004933: Improve MethodHandle interaction with libraries Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: ae1fed8d80e1 Author: ewendeli Date: 2013-02-26 06:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ae1fed8d80e1 Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 5e4c2d7f3b67 Author: ewendeli Date: 2013-02-26 20:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e4c2d7f3b67 Merge ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/sun/security/util/KeyLength.java Changeset: 4d4848124bff Author: ewendeli Date: 2013-02-27 09:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d4848124bff Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 36ff48ae6ffe Author: ewendeli Date: 2013-02-27 18:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/36ff48ae6ffe Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 931fb59eae26 Author: lana Date: 2013-03-12 19:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/931fb59eae26 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/Class.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 9528e88f8d53 Author: lana Date: 2013-03-13 23:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9528e88f8d53 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: f282190e931a Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f282190e931a Merge Changeset: 624bcb480006 Author: omajid Date: 2013-03-18 10:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/624bcb480006 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: cdcd4512c6f1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cdcd4512c6f1 Added tag jdk8-b82 for changeset 624bcb480006 ! .hgtags From john.coomes at oracle.com Thu Mar 21 22:01:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 05:01:30 +0000 Subject: hg: hsx/hotspot-main/nashorn: 134 new changesets Message-ID: <20130322050248.33D6F48312@hg.openjdk.java.net> Changeset: b8a1b238c77c Author: duke Date: 2007-12-01 00:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b8a1b238c77c Initial load + .hgignore + .jcheck/conf Changeset: 6031a0bc0ae2 Author: jcoomes Date: 2012-12-20 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6031a0bc0ae2 8005364: initial hg tags for nashorn repo Reviewed-by: amurillo + .hgtags Changeset: da1e581c933b Author: jlaskey Date: 2012-12-21 16:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/da1e581c933b 8005403: Open-source Nashorn Reviewed-by: attila, hannesw, lagergren, sundar Contributed-by: james.laskey at oracle.com, akhil.arora at oracle.com, andreas.woess at jku.at, attila.szegedi at oracle.com, hannes.wallnoefer at oracle.com, henry.jen at oracle.com, marcus.lagergren at oracle.com, pavel.semenov at oracle.com, pavel.stepanov at oracle.com, petr.hejl at oracle.com, petr.pisl at oracle.com, sundararajan.athijegannathan at oracle.com ! .hgignore + ASSEMBLY_EXCEPTION + LICENSE + README + RELEASE_README + THIRD_PARTY_README + bin/checkintest.sh + bin/fixorphantests.sh + bin/fixwhitespace.sh + bin/jjs + bin/jjs.bat + bin/jjssecure + bin/jjssecure.bat + bin/nashorn + bin/nashorn.bat + bin/rm-non-tracked.sh + bin/verbose_octane.bat + bin/verbose_octane.sh + buildtools/nasgen/README + buildtools/nasgen/build.xml + buildtools/nasgen/nasgen.iml + buildtools/nasgen/project.properties + buildtools/nasgen/src/META-INF/MANIFEST.MF + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + docs/DEVELOPER_README + docs/genshelldoc.js + make/Makefile + make/build-benchmark.xml + make/build-nasgen.xml + make/build.xml + make/nbproject/ide-file-targets.xml + make/nbproject/ide-targets.xml + make/nbproject/jdk.xml + make/nbproject/nbjdk.properties + make/nbproject/nbjdk.xml + make/nbproject/project.xml + make/project.properties + samples/counters.js + samples/letter.js + samples/parser.js + samples/shell.js + samples/test.js + samples/uniq.js + src/META-INF/MANIFEST.MF + src/META-INF/services/javax.script.ScriptEngineFactory + src/jdk/nashorn/api/scripting/NashornException.java + src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/package-info.java + src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/BranchOptimizer.java + src/jdk/nashorn/internal/codegen/ClassEmitter.java + src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompileUnit.java + src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/Emitter.java + src/jdk/nashorn/internal/codegen/Frame.java + src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Lower.java + src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/Namespace.java + src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/codegen/SharedScopeCall.java + src/jdk/nashorn/internal/codegen/Splitter.java + src/jdk/nashorn/internal/codegen/Transform.java + src/jdk/nashorn/internal/codegen/WeighNodes.java + src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/MapCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java + src/jdk/nashorn/internal/codegen/types/ArrayType.java + src/jdk/nashorn/internal/codegen/types/BitwiseType.java + src/jdk/nashorn/internal/codegen/types/BooleanType.java + src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeOps.java + src/jdk/nashorn/internal/codegen/types/IntType.java + src/jdk/nashorn/internal/codegen/types/LongType.java + src/jdk/nashorn/internal/codegen/types/NumberType.java + src/jdk/nashorn/internal/codegen/types/NumericType.java + src/jdk/nashorn/internal/codegen/types/ObjectType.java + src/jdk/nashorn/internal/codegen/types/Type.java + src/jdk/nashorn/internal/ir/AccessNode.java + src/jdk/nashorn/internal/ir/Assignment.java + src/jdk/nashorn/internal/ir/BaseNode.java + src/jdk/nashorn/internal/ir/BinaryNode.java + src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BreakNode.java + src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/CallNode.java + src/jdk/nashorn/internal/ir/CaseNode.java + src/jdk/nashorn/internal/ir/CatchNode.java + src/jdk/nashorn/internal/ir/ContinueNode.java + src/jdk/nashorn/internal/ir/DoWhileNode.java + src/jdk/nashorn/internal/ir/EmptyNode.java + src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/ForNode.java + src/jdk/nashorn/internal/ir/FunctionCall.java + src/jdk/nashorn/internal/ir/FunctionNode.java + src/jdk/nashorn/internal/ir/IdentNode.java + src/jdk/nashorn/internal/ir/IfNode.java + src/jdk/nashorn/internal/ir/IndexNode.java + src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LabeledNode.java + src/jdk/nashorn/internal/ir/LineNumberNode.java + src/jdk/nashorn/internal/ir/LiteralNode.java + src/jdk/nashorn/internal/ir/Location.java + src/jdk/nashorn/internal/ir/Node.java + src/jdk/nashorn/internal/ir/ObjectNode.java + src/jdk/nashorn/internal/ir/PropertyKey.java + src/jdk/nashorn/internal/ir/PropertyNode.java + src/jdk/nashorn/internal/ir/ReferenceNode.java + src/jdk/nashorn/internal/ir/ReturnNode.java + src/jdk/nashorn/internal/ir/RuntimeNode.java + src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/SwitchNode.java + src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TernaryNode.java + src/jdk/nashorn/internal/ir/ThrowNode.java + src/jdk/nashorn/internal/ir/TryNode.java + src/jdk/nashorn/internal/ir/TypeOverride.java + src/jdk/nashorn/internal/ir/UnaryNode.java + src/jdk/nashorn/internal/ir/VarNode.java + src/jdk/nashorn/internal/ir/WhileNode.java + src/jdk/nashorn/internal/ir/WithNode.java + src/jdk/nashorn/internal/ir/annotations/ChildNode.java + src/jdk/nashorn/internal/ir/annotations/Ignore.java + src/jdk/nashorn/internal/ir/annotations/ParentNode.java + src/jdk/nashorn/internal/ir/annotations/Reference.java + src/jdk/nashorn/internal/ir/debug/ASTWriter.java + src/jdk/nashorn/internal/ir/debug/JSONWriter.java + src/jdk/nashorn/internal/ir/debug/PrintVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java + src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java + src/jdk/nashorn/internal/objects/ArrayBufferView.java + src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java + src/jdk/nashorn/internal/objects/DateParser.java + src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java + src/jdk/nashorn/internal/objects/Global.java + src/jdk/nashorn/internal/objects/NativeArguments.java + src/jdk/nashorn/internal/objects/NativeArray.java + src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeBoolean.java + src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/objects/NativeDebug.java + src/jdk/nashorn/internal/objects/NativeError.java + src/jdk/nashorn/internal/objects/NativeEvalError.java + src/jdk/nashorn/internal/objects/NativeFloat32Array.java + src/jdk/nashorn/internal/objects/NativeFloat64Array.java + src/jdk/nashorn/internal/objects/NativeFunction.java + src/jdk/nashorn/internal/objects/NativeInt16Array.java + src/jdk/nashorn/internal/objects/NativeInt32Array.java + src/jdk/nashorn/internal/objects/NativeInt8Array.java + src/jdk/nashorn/internal/objects/NativeJSAdapter.java + src/jdk/nashorn/internal/objects/NativeJSON.java + src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/objects/NativeJavaImporter.java + src/jdk/nashorn/internal/objects/NativeMath.java + src/jdk/nashorn/internal/objects/NativeNumber.java + src/jdk/nashorn/internal/objects/NativeObject.java + src/jdk/nashorn/internal/objects/NativeRangeError.java + src/jdk/nashorn/internal/objects/NativeReferenceError.java + src/jdk/nashorn/internal/objects/NativeRegExp.java + src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + src/jdk/nashorn/internal/objects/NativeStrictArguments.java + src/jdk/nashorn/internal/objects/NativeString.java + src/jdk/nashorn/internal/objects/NativeSyntaxError.java + src/jdk/nashorn/internal/objects/NativeTypeError.java + src/jdk/nashorn/internal/objects/NativeURIError.java + src/jdk/nashorn/internal/objects/NativeUint16Array.java + src/jdk/nashorn/internal/objects/NativeUint32Array.java + src/jdk/nashorn/internal/objects/NativeUint8Array.java + src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + src/jdk/nashorn/internal/objects/PrototypeObject.java + src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Attribute.java + src/jdk/nashorn/internal/objects/annotations/Constructor.java + src/jdk/nashorn/internal/objects/annotations/Function.java + src/jdk/nashorn/internal/objects/annotations/Getter.java + src/jdk/nashorn/internal/objects/annotations/Property.java + src/jdk/nashorn/internal/objects/annotations/ScriptClass.java + src/jdk/nashorn/internal/objects/annotations/Setter.java + src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java + src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java + src/jdk/nashorn/internal/objects/annotations/Where.java + src/jdk/nashorn/internal/objects/package-info.java + src/jdk/nashorn/internal/parser/AbstractParser.java + src/jdk/nashorn/internal/parser/JSONParser.java + src/jdk/nashorn/internal/parser/Lexer.java + src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/parser/RegExp.java + src/jdk/nashorn/internal/parser/RegExpScanner.java + src/jdk/nashorn/internal/parser/Scanner.java + src/jdk/nashorn/internal/parser/Token.java + src/jdk/nashorn/internal/parser/TokenKind.java + src/jdk/nashorn/internal/parser/TokenLookup.java + src/jdk/nashorn/internal/parser/TokenStream.java + src/jdk/nashorn/internal/parser/TokenType.java + src/jdk/nashorn/internal/runtime/AccessorProperty.java + src/jdk/nashorn/internal/runtime/BitVector.java + src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/ConsString.java + src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/Debug.java + src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java + src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/ErrorManager.java + src/jdk/nashorn/internal/runtime/FindProperty.java + src/jdk/nashorn/internal/runtime/FunctionScope.java + src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/GlobalObject.java + src/jdk/nashorn/internal/runtime/JSErrorType.java + src/jdk/nashorn/internal/runtime/JSType.java + src/jdk/nashorn/internal/runtime/Logging.java + src/jdk/nashorn/internal/runtime/NashornLoader.java + src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/NumberToString.java + src/jdk/nashorn/internal/runtime/ParserException.java + src/jdk/nashorn/internal/runtime/Property.java + src/jdk/nashorn/internal/runtime/PropertyAccess.java + src/jdk/nashorn/internal/runtime/PropertyDescriptor.java + src/jdk/nashorn/internal/runtime/PropertyHashMap.java + src/jdk/nashorn/internal/runtime/PropertyListener.java + src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyMap.java + src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java + src/jdk/nashorn/internal/runtime/RegExpMatch.java + src/jdk/nashorn/internal/runtime/Scope.java + src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptLoader.java + src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Source.java + src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StructureLoader.java + src/jdk/nashorn/internal/runtime/URIUtils.java + src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + src/jdk/nashorn/internal/runtime/Version.java + src/jdk/nashorn/internal/runtime/WithObject.java + src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java + src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java + src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java + src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java + src/jdk/nashorn/internal/runtime/linker/Lookup.java + src/jdk/nashorn/internal/runtime/linker/Mangler.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java + src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java + src/jdk/nashorn/internal/runtime/linker/NashornGuards.java + src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/Option.java + src/jdk/nashorn/internal/runtime/options/OptionTemplate.java + src/jdk/nashorn/internal/runtime/options/Options.java + src/jdk/nashorn/internal/runtime/options/ValueOption.java + src/jdk/nashorn/internal/runtime/resources/Messages.properties + src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + src/jdk/nashorn/internal/runtime/resources/parser.js + src/jdk/nashorn/internal/runtime/resources/version.properties-template + src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/tools/Shell.java + src/jdk/nashorn/tools/resources/Shell.properties + src/jdk/nashorn/tools/resources/shell.js + src/netscape/javascript/JSObject.java + src/overview.html + test/README + test/examples/dual-fields-micro.js + test/examples/innerbench.js + test/examples/typechain.js + test/lib/benchmark.js + test/opt/add.js + test/opt/add_constant.js + test/opt/add_reuse_callsite.js + test/opt/add_revert2.js + test/opt/cascade_specialize.js + test/script/assert.js + test/script/basic/NASHORN-100.js + test/script/basic/NASHORN-100.js.EXPECTED + test/script/basic/NASHORN-101.js + test/script/basic/NASHORN-101.js.EXPECTED + test/script/basic/NASHORN-102.js + test/script/basic/NASHORN-102.js.EXPECTED + test/script/basic/NASHORN-103.js + test/script/basic/NASHORN-104.js + test/script/basic/NASHORN-104.js.EXPECTED + test/script/basic/NASHORN-105.js + test/script/basic/NASHORN-105.js.EXPECTED + test/script/basic/NASHORN-106.js + test/script/basic/NASHORN-106.js.EXPECTED + test/script/basic/NASHORN-107.js + test/script/basic/NASHORN-108.js + test/script/basic/NASHORN-108.js.EXPECTED + test/script/basic/NASHORN-109.js + test/script/basic/NASHORN-109.js.EXPECTED + test/script/basic/NASHORN-11.js + test/script/basic/NASHORN-11.js.EXPECTED + test/script/basic/NASHORN-111.js + test/script/basic/NASHORN-111.js.EXPECTED + test/script/basic/NASHORN-113.js + test/script/basic/NASHORN-113.js.EXPECTED + test/script/basic/NASHORN-114.js + test/script/basic/NASHORN-115.js + test/script/basic/NASHORN-115.js.EXPECTED + test/script/basic/NASHORN-117.js + test/script/basic/NASHORN-118.js + test/script/basic/NASHORN-118.js.EXPECTED + test/script/basic/NASHORN-119.js + test/script/basic/NASHORN-119.js.EXPECTED + test/script/basic/NASHORN-12.js + test/script/basic/NASHORN-120.js + test/script/basic/NASHORN-122.js + test/script/basic/NASHORN-122.js.EXPECTED + test/script/basic/NASHORN-126.js + test/script/basic/NASHORN-126.js.EXPECTED + test/script/basic/NASHORN-127.js + test/script/basic/NASHORN-127.js.EXPECTED + test/script/basic/NASHORN-130.js + test/script/basic/NASHORN-132.js + test/script/basic/NASHORN-132.js.EXPECTED + test/script/basic/NASHORN-133.js + test/script/basic/NASHORN-133.js.EXPECTED + test/script/basic/NASHORN-135.js + test/script/basic/NASHORN-136.js + test/script/basic/NASHORN-136.js.EXPECTED + test/script/basic/NASHORN-14.js + test/script/basic/NASHORN-14.js.EXPECTED + test/script/basic/NASHORN-148.js + test/script/basic/NASHORN-148.js.EXPECTED + test/script/basic/NASHORN-15.js + test/script/basic/NASHORN-15.js.EXPECTED + test/script/basic/NASHORN-153.js + test/script/basic/NASHORN-156.js + test/script/basic/NASHORN-157.js + test/script/basic/NASHORN-163.js + test/script/basic/NASHORN-163.js.EXPECTED + test/script/basic/NASHORN-164.js + test/script/basic/NASHORN-165.js + test/script/basic/NASHORN-166.js + test/script/basic/NASHORN-168.js + test/script/basic/NASHORN-168.js.EXPECTED + test/script/basic/NASHORN-169.js + test/script/basic/NASHORN-172.js + test/script/basic/NASHORN-173.js + test/script/basic/NASHORN-173.js.EXPECTED + test/script/basic/NASHORN-174.js + test/script/basic/NASHORN-175.js + test/script/basic/NASHORN-176.js + test/script/basic/NASHORN-177.js + test/script/basic/NASHORN-177.js.EXPECTED + test/script/basic/NASHORN-178.js + test/script/basic/NASHORN-178.js.EXPECTED + test/script/basic/NASHORN-179.js + test/script/basic/NASHORN-18.js + test/script/basic/NASHORN-18.js.EXPECTED + test/script/basic/NASHORN-181.js + test/script/basic/NASHORN-182.js + test/script/basic/NASHORN-183.js + test/script/basic/NASHORN-184.js + test/script/basic/NASHORN-184.js.EXPECTED + test/script/basic/NASHORN-185.js + test/script/basic/NASHORN-185.js.EXPECTED + test/script/basic/NASHORN-187.js + test/script/basic/NASHORN-188.js + test/script/basic/NASHORN-188.js.EXPECTED + test/script/basic/NASHORN-19.js + test/script/basic/NASHORN-19.js.EXPECTED + test/script/basic/NASHORN-190.js + test/script/basic/NASHORN-192.js + test/script/basic/NASHORN-194.js + test/script/basic/NASHORN-196.js + test/script/basic/NASHORN-198.js + test/script/basic/NASHORN-20.js + test/script/basic/NASHORN-20.js.EXPECTED + test/script/basic/NASHORN-201.js + test/script/basic/NASHORN-202.js + test/script/basic/NASHORN-203.js + test/script/basic/NASHORN-204.js + test/script/basic/NASHORN-205.js + test/script/basic/NASHORN-206.js + test/script/basic/NASHORN-207.js + test/script/basic/NASHORN-207_2.js + test/script/basic/NASHORN-208.js + test/script/basic/NASHORN-208.js.EXPECTED + test/script/basic/NASHORN-209.js + test/script/basic/NASHORN-209.js.EXPECTED + test/script/basic/NASHORN-21.js + test/script/basic/NASHORN-21.js.EXPECTED + test/script/basic/NASHORN-211.js + test/script/basic/NASHORN-212.js + test/script/basic/NASHORN-213.js + test/script/basic/NASHORN-215.js + test/script/basic/NASHORN-215.js.EXPECTED + test/script/basic/NASHORN-216.js + test/script/basic/NASHORN-217.js + test/script/basic/NASHORN-217.js.EXPECTED + test/script/basic/NASHORN-219.js + test/script/basic/NASHORN-219.js.EXPECTED + test/script/basic/NASHORN-22.js + test/script/basic/NASHORN-22.js.EXPECTED + test/script/basic/NASHORN-221.js + test/script/basic/NASHORN-222.js + test/script/basic/NASHORN-223.js + test/script/basic/NASHORN-225.js + test/script/basic/NASHORN-226.js + test/script/basic/NASHORN-227.js + test/script/basic/NASHORN-228.js + test/script/basic/NASHORN-229.js + test/script/basic/NASHORN-229_subtest.js + test/script/basic/NASHORN-23.js + test/script/basic/NASHORN-23.js.EXPECTED + test/script/basic/NASHORN-232.js + test/script/basic/NASHORN-234.js + test/script/basic/NASHORN-235.js + test/script/basic/NASHORN-236.js + test/script/basic/NASHORN-237.js + test/script/basic/NASHORN-239.js + test/script/basic/NASHORN-24.js + test/script/basic/NASHORN-24.js.EXPECTED + test/script/basic/NASHORN-241.js + test/script/basic/NASHORN-242.js + test/script/basic/NASHORN-245.js + test/script/basic/NASHORN-247.js + test/script/basic/NASHORN-25.js + test/script/basic/NASHORN-25.js.EXPECTED + test/script/basic/NASHORN-251.js + test/script/basic/NASHORN-252.js + test/script/basic/NASHORN-253.js + test/script/basic/NASHORN-256.js + test/script/basic/NASHORN-258.js + test/script/basic/NASHORN-258.js.EXPECTED + test/script/basic/NASHORN-26.js + test/script/basic/NASHORN-26.js.EXPECTED + test/script/basic/NASHORN-260.js + test/script/basic/NASHORN-261.js + test/script/basic/NASHORN-262.js + test/script/basic/NASHORN-263.js + test/script/basic/NASHORN-264.js + test/script/basic/NASHORN-265.js + test/script/basic/NASHORN-265.js.EXPECTED + test/script/basic/NASHORN-266.js + test/script/basic/NASHORN-269.js + test/script/basic/NASHORN-27.js + test/script/basic/NASHORN-27.js.EXPECTED + test/script/basic/NASHORN-270.js + test/script/basic/NASHORN-271.js + test/script/basic/NASHORN-275.js + test/script/basic/NASHORN-276.js + test/script/basic/NASHORN-277.js + test/script/basic/NASHORN-278.js + test/script/basic/NASHORN-28.js + test/script/basic/NASHORN-28.js.EXPECTED + test/script/basic/NASHORN-281.js + test/script/basic/NASHORN-284.js + test/script/basic/NASHORN-284.js.EXPECTED + test/script/basic/NASHORN-285.js + test/script/basic/NASHORN-285.js.EXPECTED + test/script/basic/NASHORN-288.js + test/script/basic/NASHORN-29.js + test/script/basic/NASHORN-29.js.EXPECTED + test/script/basic/NASHORN-293.js + test/script/basic/NASHORN-293.js.EXPECTED + test/script/basic/NASHORN-294.js + test/script/basic/NASHORN-296.js + test/script/basic/NASHORN-297.js + test/script/basic/NASHORN-30.js + test/script/basic/NASHORN-30.js.EXPECTED + test/script/basic/NASHORN-300.js + test/script/basic/NASHORN-301.js + test/script/basic/NASHORN-301.js.EXPECTED + test/script/basic/NASHORN-304.js + test/script/basic/NASHORN-310.js + test/script/basic/NASHORN-310.js.EXPECTED + test/script/basic/NASHORN-318.js + test/script/basic/NASHORN-318.js.EXPECTED + test/script/basic/NASHORN-32.js + test/script/basic/NASHORN-32.js.EXPECTED + test/script/basic/NASHORN-321.js + test/script/basic/NASHORN-321.js.EXPECTED + test/script/basic/NASHORN-323.js + test/script/basic/NASHORN-323.js.EXPECTED + test/script/basic/NASHORN-324.js + test/script/basic/NASHORN-33.js + test/script/basic/NASHORN-33.js.EXPECTED + test/script/basic/NASHORN-331.js + test/script/basic/NASHORN-331.js.EXPECTED + test/script/basic/NASHORN-337.js + test/script/basic/NASHORN-337.js.EXPECTED + test/script/basic/NASHORN-34.js + test/script/basic/NASHORN-34.js.EXPECTED + test/script/basic/NASHORN-340.js + test/script/basic/NASHORN-340.js.EXPECTED + test/script/basic/NASHORN-349.js + test/script/basic/NASHORN-354.js + test/script/basic/NASHORN-354.js.EXPECTED + test/script/basic/NASHORN-355.js + test/script/basic/NASHORN-355.js.EXPECTED + test/script/basic/NASHORN-36.js + test/script/basic/NASHORN-36.js.EXPECTED + test/script/basic/NASHORN-365.js + test/script/basic/NASHORN-366.js + test/script/basic/NASHORN-366.js.EXPECTED + test/script/basic/NASHORN-368.js + test/script/basic/NASHORN-368.js.EXPECTED + test/script/basic/NASHORN-37.js + test/script/basic/NASHORN-37.js.EXPECTED + test/script/basic/NASHORN-375.js + test/script/basic/NASHORN-376.js + test/script/basic/NASHORN-377.js + test/script/basic/NASHORN-377.js.EXPECTED + test/script/basic/NASHORN-378.js + test/script/basic/NASHORN-38.js + test/script/basic/NASHORN-38.js.EXPECTED + test/script/basic/NASHORN-380.js + test/script/basic/NASHORN-380.js.EXPECTED + test/script/basic/NASHORN-381.js + test/script/basic/NASHORN-382.js + test/script/basic/NASHORN-383.js + test/script/basic/NASHORN-384.js + test/script/basic/NASHORN-384.js.EXPECTED + test/script/basic/NASHORN-385.js + test/script/basic/NASHORN-385.js.EXPECTED + test/script/basic/NASHORN-389.js + test/script/basic/NASHORN-389.js.EXPECTED + test/script/basic/NASHORN-393.js + test/script/basic/NASHORN-393.js.EXPECTED + test/script/basic/NASHORN-394.js + test/script/basic/NASHORN-394.js.EXPECTED + test/script/basic/NASHORN-396.js + test/script/basic/NASHORN-397.js + test/script/basic/NASHORN-398.js + test/script/basic/NASHORN-40.js + test/script/basic/NASHORN-40.js.EXPECTED + test/script/basic/NASHORN-400.js + test/script/basic/NASHORN-400.js.EXPECTED + test/script/basic/NASHORN-401.js + test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/NASHORN-402.js + test/script/basic/NASHORN-402.js.EXPECTED + test/script/basic/NASHORN-404.js + test/script/basic/NASHORN-405.js + test/script/basic/NASHORN-405.js.EXPECTED + test/script/basic/NASHORN-406.js + test/script/basic/NASHORN-408.js + test/script/basic/NASHORN-408.js.EXPECTED + test/script/basic/NASHORN-415.js + test/script/basic/NASHORN-415.js.EXPECTED + test/script/basic/NASHORN-416.js + test/script/basic/NASHORN-417.js + test/script/basic/NASHORN-418.js + test/script/basic/NASHORN-420.js + test/script/basic/NASHORN-421.js + test/script/basic/NASHORN-423.js + test/script/basic/NASHORN-423.js.EXPECTED + test/script/basic/NASHORN-423a.js + test/script/basic/NASHORN-424.js + test/script/basic/NASHORN-424.js.EXPECTED + test/script/basic/NASHORN-425.js + test/script/basic/NASHORN-425.js.EXPECTED + test/script/basic/NASHORN-426.js + test/script/basic/NASHORN-427.js + test/script/basic/NASHORN-428.js + test/script/basic/NASHORN-429.js + test/script/basic/NASHORN-432.js + test/script/basic/NASHORN-433.js + test/script/basic/NASHORN-434.js + test/script/basic/NASHORN-435.js + test/script/basic/NASHORN-437.js + test/script/basic/NASHORN-44.js + test/script/basic/NASHORN-44.js.EXPECTED + test/script/basic/NASHORN-441.js + test/script/basic/NASHORN-441.js.EXPECTED + test/script/basic/NASHORN-442.js + test/script/basic/NASHORN-443.js + test/script/basic/NASHORN-444.js + test/script/basic/NASHORN-444.js.EXPECTED + test/script/basic/NASHORN-445.js + test/script/basic/NASHORN-446.js + test/script/basic/NASHORN-447.js + test/script/basic/NASHORN-448.js + test/script/basic/NASHORN-449.js + test/script/basic/NASHORN-449.js.EXPECTED + test/script/basic/NASHORN-45.js + test/script/basic/NASHORN-45.js.EXPECTED + test/script/basic/NASHORN-450.js + test/script/basic/NASHORN-452.js + test/script/basic/NASHORN-459.js + test/script/basic/NASHORN-46.js + test/script/basic/NASHORN-46.js.EXPECTED + test/script/basic/NASHORN-462.js + test/script/basic/NASHORN-463.js + test/script/basic/NASHORN-468.js + test/script/basic/NASHORN-47.js + test/script/basic/NASHORN-473.js + test/script/basic/NASHORN-473.js.EXPECTED + test/script/basic/NASHORN-474.js + test/script/basic/NASHORN-474.js.EXPECTED + test/script/basic/NASHORN-478.js + test/script/basic/NASHORN-48.js + test/script/basic/NASHORN-48.js.EXPECTED + test/script/basic/NASHORN-481.js + test/script/basic/NASHORN-481.js.EXPECTED + test/script/basic/NASHORN-482.js + test/script/basic/NASHORN-484.js + test/script/basic/NASHORN-484.js.EXPECTED + test/script/basic/NASHORN-486.js + test/script/basic/NASHORN-487.js + test/script/basic/NASHORN-488.js + test/script/basic/NASHORN-49.js + test/script/basic/NASHORN-49.js.EXPECTED + test/script/basic/NASHORN-490.js + test/script/basic/NASHORN-494.js + test/script/basic/NASHORN-497.js + test/script/basic/NASHORN-498.js + test/script/basic/NASHORN-499.js + test/script/basic/NASHORN-50.js + test/script/basic/NASHORN-50.js.EXPECTED + test/script/basic/NASHORN-500.js + test/script/basic/NASHORN-503.js + test/script/basic/NASHORN-503.js.EXPECTED + test/script/basic/NASHORN-51.js + test/script/basic/NASHORN-51.js.EXPECTED + test/script/basic/NASHORN-511.js + test/script/basic/NASHORN-515.js + test/script/basic/NASHORN-515.js.EXPECTED + test/script/basic/NASHORN-516.js + test/script/basic/NASHORN-52.js + test/script/basic/NASHORN-534.js + test/script/basic/NASHORN-534.js.EXPECTED + test/script/basic/NASHORN-535.js + test/script/basic/NASHORN-535.js.EXPECTED + test/script/basic/NASHORN-544.js + test/script/basic/NASHORN-55.js + test/script/basic/NASHORN-554.js + test/script/basic/NASHORN-554.js.EXPECTED + test/script/basic/NASHORN-556.js + test/script/basic/NASHORN-556.js.EXPECTED + test/script/basic/NASHORN-56.js + test/script/basic/NASHORN-56.js.EXPECTED + test/script/basic/NASHORN-562.js + test/script/basic/NASHORN-565.js + test/script/basic/NASHORN-565.js.EXPECTED + test/script/basic/NASHORN-575.js + test/script/basic/NASHORN-575.js.EXPECTED + test/script/basic/NASHORN-58.js + test/script/basic/NASHORN-58.js.EXPECTED + test/script/basic/NASHORN-59.js + test/script/basic/NASHORN-59.js.EXPECTED + test/script/basic/NASHORN-592.js + test/script/basic/NASHORN-592.js.EXPECTED + test/script/basic/NASHORN-597.js + test/script/basic/NASHORN-597.js.EXPECTED + test/script/basic/NASHORN-60.js + test/script/basic/NASHORN-60.js.EXPECTED + test/script/basic/NASHORN-609.js + test/script/basic/NASHORN-609.js.EXPECTED + test/script/basic/NASHORN-61.js + test/script/basic/NASHORN-61.js.EXPECTED + test/script/basic/NASHORN-62.js + test/script/basic/NASHORN-62.js.EXPECTED + test/script/basic/NASHORN-620.js + test/script/basic/NASHORN-620.js.EXPECTED + test/script/basic/NASHORN-623.js + test/script/basic/NASHORN-623.js.EXPECTED + test/script/basic/NASHORN-627.js + test/script/basic/NASHORN-627.js.EXPECTED + test/script/basic/NASHORN-63.js + test/script/basic/NASHORN-631.js.EXPECTED + test/script/basic/NASHORN-637.js + test/script/basic/NASHORN-637.js.EXPECTED + test/script/basic/NASHORN-638.js + test/script/basic/NASHORN-638.js.EXPECTED + test/script/basic/NASHORN-639.js + test/script/basic/NASHORN-64.js + test/script/basic/NASHORN-642.js + test/script/basic/NASHORN-642.js.EXPECTED + test/script/basic/NASHORN-646.js + test/script/basic/NASHORN-653.js + test/script/basic/NASHORN-658.js + test/script/basic/NASHORN-659.js + test/script/basic/NASHORN-66.js + test/script/basic/NASHORN-66.js.EXPECTED + test/script/basic/NASHORN-664.js + test/script/basic/NASHORN-665.js + test/script/basic/NASHORN-67.js + test/script/basic/NASHORN-67.js.EXPECTED + test/script/basic/NASHORN-678.js + test/script/basic/NASHORN-68.js + test/script/basic/NASHORN-68.js.EXPECTED + test/script/basic/NASHORN-689.js + test/script/basic/NASHORN-689.js.EXPECTED + test/script/basic/NASHORN-69.js + test/script/basic/NASHORN-69.js.EXPECTED + test/script/basic/NASHORN-691.js + test/script/basic/NASHORN-691.js.EXPECTED + test/script/basic/NASHORN-694.js + test/script/basic/NASHORN-694.js.EXPECTED + test/script/basic/NASHORN-697.js + test/script/basic/NASHORN-703.js + test/script/basic/NASHORN-703.js.EXPECTED + test/script/basic/NASHORN-703a.js + test/script/basic/NASHORN-703a.js.EXPECTED + test/script/basic/NASHORN-705.js + test/script/basic/NASHORN-71.js + test/script/basic/NASHORN-71.js.EXPECTED + test/script/basic/NASHORN-710.js + test/script/basic/NASHORN-711.js + test/script/basic/NASHORN-711.js.EXPECTED + test/script/basic/NASHORN-72.js + test/script/basic/NASHORN-72.js.EXPECTED + test/script/basic/NASHORN-722.js + test/script/basic/NASHORN-73.js + test/script/basic/NASHORN-73.js.EXPECTED + test/script/basic/NASHORN-737.js + test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/NASHORN-74.js + test/script/basic/NASHORN-74.js.EXPECTED + test/script/basic/NASHORN-740.js + test/script/basic/NASHORN-740.js.EXPECTED + test/script/basic/NASHORN-75.js + test/script/basic/NASHORN-75.js.EXPECTED + test/script/basic/NASHORN-758.js + test/script/basic/NASHORN-759.js + test/script/basic/NASHORN-759.js.EXPECTED + test/script/basic/NASHORN-760.js + test/script/basic/NASHORN-768.js + test/script/basic/NASHORN-778.js + test/script/basic/NASHORN-78.js + test/script/basic/NASHORN-79.js + test/script/basic/NASHORN-79.js.EXPECTED + test/script/basic/NASHORN-792.js + test/script/basic/NASHORN-792.js.EXPECTED + test/script/basic/NASHORN-80.js + test/script/basic/NASHORN-80.js.EXPECTED + test/script/basic/NASHORN-81.js + test/script/basic/NASHORN-833.js + test/script/basic/NASHORN-833.js.EXPECTED + test/script/basic/NASHORN-85.js + test/script/basic/NASHORN-85.js.EXPECTED + test/script/basic/NASHORN-86.js + test/script/basic/NASHORN-87.js + test/script/basic/NASHORN-89.js + test/script/basic/NASHORN-90.js + test/script/basic/NASHORN-90.js.EXPECTED + test/script/basic/NASHORN-91.js + test/script/basic/NASHORN-91.js.EXPECTED + test/script/basic/NASHORN-92.js + test/script/basic/NASHORN-92.js.EXPECTED + test/script/basic/NASHORN-93.js + test/script/basic/NASHORN-95.js + test/script/basic/NASHORN-95.js.EXPECTED + test/script/basic/NASHORN-96.js + test/script/basic/NASHORN-96.js.EXPECTED + test/script/basic/NASHORN-97.js + test/script/basic/NASHORN-98.js + test/script/basic/NASHORN-98.js.EXPECTED + test/script/basic/NASHORN-99.js + test/script/basic/addition.js + test/script/basic/addition.js.EXPECTED + test/script/basic/allgettersetters.js + test/script/basic/andor.js + test/script/basic/andor.js.EXPECTED + test/script/basic/anonrecur.js + test/script/basic/anonrecur.js.EXPECTED + test/script/basic/applycall.js + test/script/basic/applycall.js.EXPECTED + test/script/basic/args.js + test/script/basic/args.js.EXPECTED + test/script/basic/arity.js + test/script/basic/arity.js.EXPECTED + test/script/basic/arrayprotoclass.js + test/script/basic/arrayprotoclass.js.EXPECTED + test/script/basic/arrays.js + test/script/basic/arrays.js.EXPECTED + test/script/basic/arrays2.js + test/script/basic/arrays2.js.EXPECTED + test/script/basic/arraysIntKey.js + test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrayset.js + test/script/basic/arrayset.js.EXPECTED + test/script/basic/arrayundefined.js + test/script/basic/arrayundefined.js.EXPECTED + test/script/basic/assign.js + test/script/basic/assign.js.EXPECTED + test/script/basic/bitwise_and.js + test/script/basic/bitwise_and.js.EXPECTED + test/script/basic/booleangetter.js + test/script/basic/booleangetter.js.EXPECTED + test/script/basic/builtin.js + test/script/basic/builtin.js.EXPECTED + test/script/basic/builtin_assign.js + test/script/basic/builtin_assign.js.EXPECTED + test/script/basic/builtinchain.js + test/script/basic/builtinchain.js.EXPECTED + test/script/basic/calllink.js + test/script/basic/calllink.js.EXPECTED + test/script/basic/closure.js + test/script/basic/closure.js.EXPECTED + test/script/basic/commandargs.js + test/script/basic/commandargs.js.EXPECTED + test/script/basic/compile-octane.js + test/script/basic/compile-octane.js.EXPECTED + test/script/basic/condassign.js + test/script/basic/condassign.js.EXPECTED + test/script/basic/construct.js + test/script/basic/construct.js.EXPECTED + test/script/basic/constructorname.js + test/script/basic/constructorname.js.EXPECTED + test/script/basic/date.js + test/script/basic/date.js.EXPECTED + test/script/basic/dateparse.js + test/script/basic/dateparse.js.EXPECTED + test/script/basic/decinc.js + test/script/basic/decinc.js.EXPECTED + test/script/basic/delete.js + test/script/basic/delete.js.EXPECTED + test/script/basic/delete2.js + test/script/basic/delete2.js.EXPECTED + test/script/basic/dotpropname.js + test/script/basic/dotpropname.js.EXPECTED + test/script/basic/doublecache.js + test/script/basic/doublecache.js.EXPECTED + test/script/basic/enumeration.js + test/script/basic/enumeration.js.EXPECTED + test/script/basic/errors.js + test/script/basic/errors.js.EXPECTED + test/script/basic/errorstack.js + test/script/basic/errorstack.js.EXPECTED + test/script/basic/eval.js + test/script/basic/eval.js.EXPECTED + test/script/basic/evalreturn.js + test/script/basic/evalreturn.js.EXPECTED + test/script/basic/exprclosure.js + test/script/basic/exprclosure.js.EXPECTED + test/script/basic/extensibility.js + test/script/basic/extensibility.js.EXPECTED + test/script/basic/fileline.js + test/script/basic/fileline.js.EXPECTED + test/script/basic/finally-catchalls.js + test/script/basic/finally-catchalls.js.EXPECTED + test/script/basic/finallyreturn.js + test/script/basic/finallyreturn.js.EXPECTED + test/script/basic/forin.js + test/script/basic/forin.js.EXPECTED + test/script/basic/forin2.js + test/script/basic/forin2.js.EXPECTED + test/script/basic/funcarray.js + test/script/basic/funcarray.js.EXPECTED + test/script/basic/funcbind.js + test/script/basic/funcbind.js.EXPECTED + test/script/basic/funcconstructor.js + test/script/basic/funcconstructor.js.EXPECTED + test/script/basic/getclassname.js + test/script/basic/getenv.js + test/script/basic/getenv.js.EXPECTED + test/script/basic/getter_callsite.js + test/script/basic/getter_callsite.js.EXPECTED + test/script/basic/gettercalls.js + test/script/basic/gettercalls.js.EXPECTED + test/script/basic/getterfunc.js + test/script/basic/getterfunc.js.EXPECTED + test/script/basic/gettersetter.js + test/script/basic/gettersetter.js.EXPECTED + test/script/basic/globalaccess.js + test/script/basic/globalaccess.js.EXPECTED + test/script/basic/globals.js + test/script/basic/globals.js.EXPECTED + test/script/basic/globalscope.js + test/script/basic/globalscope.js.EXPECTED + test/script/basic/hello.js + test/script/basic/hello.js.EXPECTED + test/script/basic/herestr_operator.js + test/script/basic/herestr_operator.js.EXPECTED + test/script/basic/illegaljavaname.js + test/script/basic/illegaljavaname.js.EXPECTED + test/script/basic/incheck.js + test/script/basic/incheck.js.EXPECTED + test/script/basic/indexedcall.js + test/script/basic/indexedcall.js.EXPECTED + test/script/basic/info.js + test/script/basic/info.js.EXPECTED + test/script/basic/inherited_nonwritable.js + test/script/basic/instanceof.js + test/script/basic/instanceof.js.EXPECTED + test/script/basic/instanceof2.js + test/script/basic/instanceof2.js.EXPECTED + test/script/basic/interfaces.js + test/script/basic/interfaces.js.EXPECTED + test/script/basic/iterator.js + test/script/basic/iterator.js.EXPECTED + test/script/basic/java.js + test/script/basic/java.js.EXPECTED + test/script/basic/javaarray.js + test/script/basic/javaarray.js.EXPECTED + test/script/basic/javaarrayconversion.js + test/script/basic/javaarrayconversion.js.EXPECTED + test/script/basic/javaexceptions.js + test/script/basic/javaexceptions.js.EXPECTED + test/script/basic/javaimporter.js + test/script/basic/javaimporter.js.EXPECTED + test/script/basic/javainnerclasses.js + test/script/basic/javainnerclasses.js.EXPECTED + test/script/basic/javasigcall.js + test/script/basic/javasigcall.js.EXPECTED + test/script/basic/jquery.js + test/script/basic/jquery.js.EXPECTED + test/script/basic/jsadapter.js + test/script/basic/jsadapter.js.EXPECTED + test/script/basic/jsadapterlink.js + test/script/basic/jsadapterlink.js.EXPECTED + test/script/basic/json.js + test/script/basic/json.js.EXPECTED + test/script/basic/list.js + test/script/basic/list.js.EXPECTED + test/script/basic/literal.js + test/script/basic/literal.js.EXPECTED + test/script/basic/load.js + test/script/basic/load.js.EXPECTED + test/script/basic/loadedfile.js + test/script/basic/localundef.js + test/script/basic/localundef.js.EXPECTED + test/script/basic/map.js + test/script/basic/map.js.EXPECTED + test/script/basic/math.js + test/script/basic/math.js.EXPECTED + test/script/basic/minuszero.js + test/script/basic/minuszero.js.EXPECTED + test/script/basic/module.js + test/script/basic/moduleload.js + test/script/basic/moduleload.js.EXPECTED + test/script/basic/nashorn2.js + test/script/basic/nashorn2.js.EXPECTED + test/script/basic/natives.js + test/script/basic/natives.js.EXPECTED + test/script/basic/new.js + test/script/basic/new.js.EXPECTED + test/script/basic/newexpr.js + test/script/basic/newexpr.js.EXPECTED + test/script/basic/newnew.js + test/script/basic/newnew.js.EXPECTED + test/script/basic/nonconstructors.js + test/script/basic/nonconstructors.js.EXPECTED + test/script/basic/nosuchmethod.js + test/script/basic/nosuchmethod.js.EXPECTED + test/script/basic/nosuchproperty.js + test/script/basic/nosuchproperty.js.EXPECTED + test/script/basic/number.js + test/script/basic/number.js.EXPECTED + test/script/basic/numberstring.js + test/script/basic/numberstring.js.EXPECTED + test/script/basic/objectprops.js + test/script/basic/objectprops.js.EXPECTED + test/script/basic/objects.js + test/script/basic/objects.js.EXPECTED + test/script/basic/options.js + test/script/basic/options.js.EXPECTED + test/script/basic/propchange.js + test/script/basic/propchange.js.EXPECTED + test/script/basic/propertycheck.js + test/script/basic/propertycheck.js.EXPECTED + test/script/basic/proto.js.EXPECTED + test/script/basic/prototype.js + test/script/basic/prototype.js.EXPECTED + test/script/basic/pushpull.js + test/script/basic/pushpull.js.EXPECTED + test/script/basic/regex.js + test/script/basic/regex.js.EXPECTED + test/script/basic/regexp_flags.js + test/script/basic/run-octane.js + test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED + test/script/basic/samfunc.js + test/script/basic/samfunc.js.EXPECTED + test/script/basic/scripting.js + test/script/basic/scripting.js.EXPECTED + test/script/basic/sealfreeze.js + test/script/basic/sealfreeze.js.EXPECTED + test/script/basic/setlength.js + test/script/basic/setlength.js.EXPECTED + test/script/basic/stdin.js + test/script/basic/stdin.js.EXPECTED + test/script/basic/strings.js + test/script/basic/strings.js.EXPECTED + test/script/basic/throws.js + test/script/basic/throws.js.EXPECTED + test/script/basic/tosource.js + test/script/basic/tosource.js.EXPECTED + test/script/basic/tostring.js + test/script/basic/tostring.js.EXPECTED + test/script/basic/try.js + test/script/basic/try.js.EXPECTED + test/script/basic/trybreakcont.js + test/script/basic/trybreakcont.js.EXPECTED + test/script/basic/trycatch.js + test/script/basic/trycatch.js.EXPECTED + test/script/basic/trycatchfor.js + test/script/basic/trycatchfor.js.EXPECTED + test/script/basic/tryfinallyreturn.js + test/script/basic/tryfinallyreturn.js.EXPECTED + test/script/basic/tryforbreak.js + test/script/basic/tryforbreak.js.EXPECTED + test/script/basic/typechange.js + test/script/basic/typechange.js.EXPECTED + test/script/basic/typeof.js + test/script/basic/typeof.js.EXPECTED + test/script/basic/typeof2.js + test/script/basic/typeof2.js.EXPECTED + test/script/basic/undefined.js + test/script/basic/undefined.js.EXPECTED + test/script/basic/underscore.js + test/script/basic/underscore.js.EXPECTED + test/script/basic/varargs.js + test/script/basic/varargs.js.EXPECTED + test/script/basic/void.js + test/script/basic/void.js.EXPECTED + test/script/basic/with.js + test/script/basic/with.js.EXPECTED + test/script/basic/withprimitive.js + test/script/basic/withprimitive.js.EXPECTED + test/script/basic/writable_relink.js + test/script/basic/writable_relink.js.EXPECTED + test/script/basic/xmlStrings.js.EXPECTED + test/script/basic/xorassign.js + test/script/basic/xorassign.js.EXPECTED + test/script/basic/yui.js + test/script/basic/yui.js.EXPECTED + test/script/error/NASHORN-154/README + test/script/error/NASHORN-154/function_mult_params_in_strict.js + test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED + test/script/error/NASHORN-154/improper_return_break_continue.js + test/script/error/NASHORN-154/improper_return_break_continue.js.EXPECTED + test/script/error/NASHORN-154/invalid_lvalue.js + test/script/error/NASHORN-154/invalid_lvalue.js.EXPECTED + test/script/error/NASHORN-154/literal_data_and_accessor.js + test/script/error/NASHORN-154/literal_data_and_accessor.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_getters.js + test/script/error/NASHORN-154/literal_mult_getters.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js.EXPECTED + test/script/error/NASHORN-154/with_in_strict.js + test/script/error/NASHORN-154/with_in_strict.js.EXPECTED + test/script/error/NASHORN-214.js + test/script/error/NASHORN-214.js.EXPECTED + test/script/error/NASHORN-35.js + test/script/error/NASHORN-35.js.EXPECTED + test/script/error/NASHORN-39.js + test/script/error/NASHORN-39.js.EXPECTED + test/script/error/NASHORN-568.js + test/script/error/NASHORN-568.js.EXPECTED + test/script/error/NASHORN-57.js + test/script/error/NASHORN-57.js.EXPECTED + test/script/error/NASHORN-668.js + test/script/error/NASHORN-668.js.EXPECTED + test/script/error/quotemissing.js + test/script/error/quotemissing.js.EXPECTED + test/script/error/strictmode.js + test/script/error/strictmode.js.EXPECTED + test/script/representations/NASHORN-592a.js + test/script/sandbox/NASHORN-525.js + test/script/sandbox/README + test/script/sandbox/classloader.js + test/script/sandbox/classloader.js.EXPECTED + test/script/sandbox/doprivileged.js + test/script/sandbox/doprivileged.js.EXPECTED + test/script/sandbox/exit.js + test/script/sandbox/exit.js.EXPECTED + test/script/sandbox/file.js + test/script/sandbox/file.js.EXPECTED + test/script/sandbox/javaextend.js + test/script/sandbox/javaextend.js.EXPECTED + test/script/sandbox/loadLibrary.js + test/script/sandbox/net.js + test/script/sandbox/net.js.EXPECTED + test/script/sandbox/property.js + test/script/sandbox/property.js.EXPECTED + test/script/sandbox/reflection.js + test/script/sandbox/reflection.js.EXPECTED + test/script/sandbox/runnable.js + test/script/sandbox/runnable.js.EXPECTED + test/script/sandbox/unsafe.js + test/script/sandbox/unsafe.js.EXPECTED + test/script/test262.js + test/script/test262_single.js + test/src/UnnamedPackageTestCallback.java + test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/Window.java + test/src/jdk/nashorn/api/scripting/WindowEventHandler.java + test/src/jdk/nashorn/internal/access/BooleanAccessTest.java + test/src/jdk/nashorn/internal/access/MethodAccessTest.java + test/src/jdk/nashorn/internal/access/NumberAccessTest.java + test/src/jdk/nashorn/internal/access/NumberBoxingTest.java + test/src/jdk/nashorn/internal/access/ObjectAccessTest.java + test/src/jdk/nashorn/internal/access/Person.java + test/src/jdk/nashorn/internal/access/SharedObject.java + test/src/jdk/nashorn/internal/access/StringAccessTest.java + test/src/jdk/nashorn/internal/codegen/CompilerTest.java + test/src/jdk/nashorn/internal/parser/ParserTest.java + test/src/jdk/nashorn/internal/performance/AuroraWrapper.java + test/src/jdk/nashorn/internal/performance/OctaneTest.java + test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java + test/src/jdk/nashorn/internal/performance/SplayTest.java + test/src/jdk/nashorn/internal/runtime/ContextTest.java + test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java + test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java + test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java + test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java + test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java + test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/ScriptTest.java + test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/TestConfig.java + test/src/jdk/nashorn/internal/test/framework/TestFinder.java + test/src/jdk/nashorn/internal/test/framework/TestHelper.java + test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java + test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/internal/test/models/FinalClass.java + test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/internal/test/models/NonPublicClass.java + test/src/jdk/nashorn/internal/test/models/OuterClass.java + test/src/jdk/nashorn/internal/test/models/OverloadedSam.java + test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: b4b05457b8b2 Author: jlaskey Date: 2012-12-22 08:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b4b05457b8b2 8005440: Improve .hgignore filtering for Nashorn repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: 3a7e1580bc0a Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3a7e1580bc0a 8005666: Add webrev to .hgignore Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: c6e194450af7 Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c6e194450af7 8005665: JavaDoc should only display public interfaces Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/build.xml Changeset: 5a1b0714df0e Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5a1b0714df0e 8005663: Update copyright year to 2013 Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! bin/checkintest.sh ! bin/fixorphantests.sh ! bin/fixwhitespace.sh ! bin/jjs ! bin/jjs.bat ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashorn ! bin/nashorn.bat ! bin/rm-non-tracked.sh ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! buildtools/nasgen/build.xml ! buildtools/nasgen/nasgen.iml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! docs/genshelldoc.js ! make/Makefile ! make/build-benchmark.xml ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-file-targets.xml ! make/nbproject/ide-targets.xml ! make/nbproject/jdk.xml ! make/nbproject/nbjdk.properties ! make/nbproject/nbjdk.xml ! make/nbproject/project.xml ! make/project.properties ! samples/counters.js ! samples/letter.js ! samples/parser.js ! samples/shell.js ! samples/test.js ! samples/uniq.js ! src/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/package-info.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/Emitter.java ! src/jdk/nashorn/internal/codegen/Frame.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/ArrayType.java ! src/jdk/nashorn/internal/codegen/types/BitwiseType.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/NumericType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyKey.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/annotations/ChildNode.java ! src/jdk/nashorn/internal/ir/annotations/Ignore.java ! src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk/nashorn/internal/objects/annotations/Constructor.java ! src/jdk/nashorn/internal/objects/annotations/Function.java ! src/jdk/nashorn/internal/objects/annotations/Getter.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/objects/annotations/ScriptClass.java ! src/jdk/nashorn/internal/objects/annotations/Setter.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk/nashorn/internal/objects/annotations/Where.java ! src/jdk/nashorn/internal/objects/package-info.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/RegExp.java ! src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/parser/Token.java ! src/jdk/nashorn/internal/parser/TokenKind.java ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSErrorType.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/NumberToString.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/Version.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Mangler.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/options/ValueOption.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! src/jdk/nashorn/internal/runtime/resources/version.properties-template ! src/jdk/nashorn/internal/scripts/JO$.java ! src/jdk/nashorn/internal/scripts/JS$.java ! src/jdk/nashorn/tools/Shell.java ! src/jdk/nashorn/tools/resources/Shell.properties ! src/jdk/nashorn/tools/resources/shell.js ! src/netscape/javascript/JSObject.java ! src/overview.html ! test/examples/dual-fields-micro.js ! test/examples/innerbench.js ! test/examples/typechain.js ! test/lib/benchmark.js ! test/opt/add.js ! test/opt/add_constant.js ! test/opt/add_reuse_callsite.js ! test/opt/add_revert2.js ! test/opt/cascade_specialize.js ! test/script/assert.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-101.js ! test/script/basic/NASHORN-102.js ! test/script/basic/NASHORN-103.js ! test/script/basic/NASHORN-104.js ! test/script/basic/NASHORN-105.js ! test/script/basic/NASHORN-106.js ! test/script/basic/NASHORN-107.js ! test/script/basic/NASHORN-108.js ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-11.js ! test/script/basic/NASHORN-111.js ! test/script/basic/NASHORN-113.js ! test/script/basic/NASHORN-114.js ! test/script/basic/NASHORN-115.js ! test/script/basic/NASHORN-117.js ! test/script/basic/NASHORN-118.js ! test/script/basic/NASHORN-119.js ! test/script/basic/NASHORN-12.js ! test/script/basic/NASHORN-120.js ! test/script/basic/NASHORN-122.js ! test/script/basic/NASHORN-126.js ! test/script/basic/NASHORN-127.js ! test/script/basic/NASHORN-130.js ! test/script/basic/NASHORN-132.js ! test/script/basic/NASHORN-133.js ! test/script/basic/NASHORN-135.js ! test/script/basic/NASHORN-136.js ! test/script/basic/NASHORN-14.js ! test/script/basic/NASHORN-148.js ! test/script/basic/NASHORN-15.js ! test/script/basic/NASHORN-153.js ! test/script/basic/NASHORN-156.js ! test/script/basic/NASHORN-157.js ! test/script/basic/NASHORN-163.js ! test/script/basic/NASHORN-164.js ! test/script/basic/NASHORN-165.js ! test/script/basic/NASHORN-166.js ! test/script/basic/NASHORN-168.js ! test/script/basic/NASHORN-169.js ! test/script/basic/NASHORN-172.js ! test/script/basic/NASHORN-173.js ! test/script/basic/NASHORN-174.js ! test/script/basic/NASHORN-175.js ! test/script/basic/NASHORN-176.js ! test/script/basic/NASHORN-177.js ! test/script/basic/NASHORN-178.js ! test/script/basic/NASHORN-179.js ! test/script/basic/NASHORN-18.js ! test/script/basic/NASHORN-181.js ! test/script/basic/NASHORN-182.js ! test/script/basic/NASHORN-183.js ! test/script/basic/NASHORN-184.js ! test/script/basic/NASHORN-185.js ! test/script/basic/NASHORN-187.js ! test/script/basic/NASHORN-188.js ! test/script/basic/NASHORN-19.js ! test/script/basic/NASHORN-190.js ! test/script/basic/NASHORN-192.js ! test/script/basic/NASHORN-194.js ! test/script/basic/NASHORN-196.js ! test/script/basic/NASHORN-198.js ! test/script/basic/NASHORN-20.js ! test/script/basic/NASHORN-201.js ! test/script/basic/NASHORN-202.js ! test/script/basic/NASHORN-203.js ! test/script/basic/NASHORN-204.js ! test/script/basic/NASHORN-205.js ! test/script/basic/NASHORN-206.js ! test/script/basic/NASHORN-207.js ! test/script/basic/NASHORN-207_2.js ! test/script/basic/NASHORN-208.js ! test/script/basic/NASHORN-209.js ! test/script/basic/NASHORN-21.js ! test/script/basic/NASHORN-211.js ! test/script/basic/NASHORN-212.js ! test/script/basic/NASHORN-213.js ! test/script/basic/NASHORN-215.js ! test/script/basic/NASHORN-216.js ! test/script/basic/NASHORN-217.js ! test/script/basic/NASHORN-219.js ! test/script/basic/NASHORN-22.js ! test/script/basic/NASHORN-221.js ! test/script/basic/NASHORN-222.js ! test/script/basic/NASHORN-223.js ! test/script/basic/NASHORN-225.js ! test/script/basic/NASHORN-226.js ! test/script/basic/NASHORN-227.js ! test/script/basic/NASHORN-228.js ! test/script/basic/NASHORN-229.js ! test/script/basic/NASHORN-229_subtest.js ! test/script/basic/NASHORN-23.js ! test/script/basic/NASHORN-232.js ! test/script/basic/NASHORN-234.js ! test/script/basic/NASHORN-235.js ! test/script/basic/NASHORN-236.js ! test/script/basic/NASHORN-237.js ! test/script/basic/NASHORN-239.js ! test/script/basic/NASHORN-24.js ! test/script/basic/NASHORN-241.js ! test/script/basic/NASHORN-242.js ! test/script/basic/NASHORN-245.js ! test/script/basic/NASHORN-247.js ! test/script/basic/NASHORN-25.js ! test/script/basic/NASHORN-251.js ! test/script/basic/NASHORN-252.js ! test/script/basic/NASHORN-253.js ! test/script/basic/NASHORN-256.js ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-26.js ! test/script/basic/NASHORN-260.js ! test/script/basic/NASHORN-261.js ! test/script/basic/NASHORN-262.js ! test/script/basic/NASHORN-263.js ! test/script/basic/NASHORN-264.js ! test/script/basic/NASHORN-265.js ! test/script/basic/NASHORN-266.js ! test/script/basic/NASHORN-269.js ! test/script/basic/NASHORN-27.js ! test/script/basic/NASHORN-270.js ! test/script/basic/NASHORN-271.js ! test/script/basic/NASHORN-275.js ! test/script/basic/NASHORN-276.js ! test/script/basic/NASHORN-277.js ! test/script/basic/NASHORN-278.js ! test/script/basic/NASHORN-28.js ! test/script/basic/NASHORN-281.js ! test/script/basic/NASHORN-284.js ! test/script/basic/NASHORN-285.js ! test/script/basic/NASHORN-288.js ! test/script/basic/NASHORN-29.js ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-294.js ! test/script/basic/NASHORN-296.js ! test/script/basic/NASHORN-297.js ! test/script/basic/NASHORN-30.js ! test/script/basic/NASHORN-300.js ! test/script/basic/NASHORN-301.js ! test/script/basic/NASHORN-304.js ! test/script/basic/NASHORN-310.js ! test/script/basic/NASHORN-318.js ! test/script/basic/NASHORN-32.js ! test/script/basic/NASHORN-321.js ! test/script/basic/NASHORN-323.js ! test/script/basic/NASHORN-324.js ! test/script/basic/NASHORN-33.js ! test/script/basic/NASHORN-331.js ! test/script/basic/NASHORN-337.js ! test/script/basic/NASHORN-34.js ! test/script/basic/NASHORN-340.js ! test/script/basic/NASHORN-349.js ! test/script/basic/NASHORN-354.js ! test/script/basic/NASHORN-355.js ! test/script/basic/NASHORN-36.js ! test/script/basic/NASHORN-365.js ! test/script/basic/NASHORN-366.js ! test/script/basic/NASHORN-368.js ! test/script/basic/NASHORN-37.js ! test/script/basic/NASHORN-375.js ! test/script/basic/NASHORN-376.js ! test/script/basic/NASHORN-377.js ! test/script/basic/NASHORN-378.js ! test/script/basic/NASHORN-38.js ! test/script/basic/NASHORN-380.js ! test/script/basic/NASHORN-381.js ! test/script/basic/NASHORN-382.js ! test/script/basic/NASHORN-383.js ! test/script/basic/NASHORN-384.js ! test/script/basic/NASHORN-385.js ! test/script/basic/NASHORN-389.js ! test/script/basic/NASHORN-393.js ! test/script/basic/NASHORN-394.js ! test/script/basic/NASHORN-396.js ! test/script/basic/NASHORN-397.js ! test/script/basic/NASHORN-398.js ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-400.js ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-402.js ! test/script/basic/NASHORN-404.js ! test/script/basic/NASHORN-405.js ! test/script/basic/NASHORN-406.js ! test/script/basic/NASHORN-408.js ! test/script/basic/NASHORN-415.js ! test/script/basic/NASHORN-416.js ! test/script/basic/NASHORN-417.js ! test/script/basic/NASHORN-418.js ! test/script/basic/NASHORN-420.js ! test/script/basic/NASHORN-421.js ! test/script/basic/NASHORN-423.js ! test/script/basic/NASHORN-423a.js ! test/script/basic/NASHORN-424.js ! test/script/basic/NASHORN-425.js ! test/script/basic/NASHORN-426.js ! test/script/basic/NASHORN-427.js ! test/script/basic/NASHORN-428.js ! test/script/basic/NASHORN-429.js ! test/script/basic/NASHORN-432.js ! test/script/basic/NASHORN-433.js ! test/script/basic/NASHORN-434.js ! test/script/basic/NASHORN-435.js ! test/script/basic/NASHORN-437.js ! test/script/basic/NASHORN-44.js ! test/script/basic/NASHORN-441.js ! test/script/basic/NASHORN-442.js ! test/script/basic/NASHORN-443.js ! test/script/basic/NASHORN-444.js ! test/script/basic/NASHORN-445.js ! test/script/basic/NASHORN-446.js ! test/script/basic/NASHORN-447.js ! test/script/basic/NASHORN-448.js ! test/script/basic/NASHORN-449.js ! test/script/basic/NASHORN-45.js ! test/script/basic/NASHORN-450.js ! test/script/basic/NASHORN-452.js ! test/script/basic/NASHORN-459.js ! test/script/basic/NASHORN-46.js ! test/script/basic/NASHORN-462.js ! test/script/basic/NASHORN-463.js ! test/script/basic/NASHORN-468.js ! test/script/basic/NASHORN-47.js ! test/script/basic/NASHORN-473.js ! test/script/basic/NASHORN-474.js ! test/script/basic/NASHORN-478.js ! test/script/basic/NASHORN-48.js ! test/script/basic/NASHORN-481.js ! test/script/basic/NASHORN-482.js ! test/script/basic/NASHORN-484.js ! test/script/basic/NASHORN-486.js ! test/script/basic/NASHORN-487.js ! test/script/basic/NASHORN-488.js ! test/script/basic/NASHORN-49.js ! test/script/basic/NASHORN-490.js ! test/script/basic/NASHORN-494.js ! test/script/basic/NASHORN-497.js ! test/script/basic/NASHORN-498.js ! test/script/basic/NASHORN-499.js ! test/script/basic/NASHORN-50.js ! test/script/basic/NASHORN-500.js ! test/script/basic/NASHORN-503.js ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-511.js ! test/script/basic/NASHORN-515.js ! test/script/basic/NASHORN-516.js ! test/script/basic/NASHORN-52.js ! test/script/basic/NASHORN-534.js ! test/script/basic/NASHORN-535.js ! test/script/basic/NASHORN-544.js ! test/script/basic/NASHORN-55.js ! test/script/basic/NASHORN-554.js ! test/script/basic/NASHORN-556.js ! test/script/basic/NASHORN-56.js ! test/script/basic/NASHORN-562.js ! test/script/basic/NASHORN-565.js ! test/script/basic/NASHORN-575.js ! test/script/basic/NASHORN-58.js ! test/script/basic/NASHORN-59.js ! test/script/basic/NASHORN-592.js ! test/script/basic/NASHORN-597.js ! test/script/basic/NASHORN-60.js ! test/script/basic/NASHORN-609.js ! test/script/basic/NASHORN-61.js ! test/script/basic/NASHORN-62.js ! test/script/basic/NASHORN-620.js ! test/script/basic/NASHORN-623.js ! test/script/basic/NASHORN-627.js ! test/script/basic/NASHORN-63.js ! test/script/basic/NASHORN-637.js ! test/script/basic/NASHORN-638.js ! test/script/basic/NASHORN-639.js ! test/script/basic/NASHORN-64.js ! test/script/basic/NASHORN-642.js ! test/script/basic/NASHORN-646.js ! test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-658.js ! test/script/basic/NASHORN-659.js ! test/script/basic/NASHORN-66.js ! test/script/basic/NASHORN-664.js ! test/script/basic/NASHORN-665.js ! test/script/basic/NASHORN-67.js ! test/script/basic/NASHORN-678.js ! test/script/basic/NASHORN-68.js ! test/script/basic/NASHORN-689.js ! test/script/basic/NASHORN-69.js ! test/script/basic/NASHORN-691.js ! test/script/basic/NASHORN-694.js ! test/script/basic/NASHORN-697.js ! test/script/basic/NASHORN-703.js ! test/script/basic/NASHORN-703a.js ! test/script/basic/NASHORN-705.js ! test/script/basic/NASHORN-71.js ! test/script/basic/NASHORN-710.js ! test/script/basic/NASHORN-711.js ! test/script/basic/NASHORN-72.js ! test/script/basic/NASHORN-722.js ! test/script/basic/NASHORN-73.js ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-74.js ! test/script/basic/NASHORN-740.js ! test/script/basic/NASHORN-75.js ! test/script/basic/NASHORN-758.js ! test/script/basic/NASHORN-759.js ! test/script/basic/NASHORN-760.js ! test/script/basic/NASHORN-768.js ! test/script/basic/NASHORN-778.js ! test/script/basic/NASHORN-78.js ! test/script/basic/NASHORN-79.js ! test/script/basic/NASHORN-792.js ! test/script/basic/NASHORN-80.js ! test/script/basic/NASHORN-81.js ! test/script/basic/NASHORN-833.js ! test/script/basic/NASHORN-85.js ! test/script/basic/NASHORN-86.js ! test/script/basic/NASHORN-87.js ! test/script/basic/NASHORN-89.js ! test/script/basic/NASHORN-90.js ! test/script/basic/NASHORN-91.js ! test/script/basic/NASHORN-92.js ! test/script/basic/NASHORN-93.js ! test/script/basic/NASHORN-95.js ! test/script/basic/NASHORN-96.js ! test/script/basic/NASHORN-97.js ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-99.js ! test/script/basic/addition.js ! test/script/basic/allgettersetters.js ! test/script/basic/andor.js ! test/script/basic/anonrecur.js ! test/script/basic/applycall.js ! test/script/basic/args.js ! test/script/basic/arity.js ! test/script/basic/arrayprotoclass.js ! test/script/basic/arrays.js ! test/script/basic/arrays2.js ! test/script/basic/arraysIntKey.js ! test/script/basic/arrayset.js ! test/script/basic/arrayundefined.js ! test/script/basic/assign.js ! test/script/basic/bitwise_and.js ! test/script/basic/booleangetter.js ! test/script/basic/builtin.js ! test/script/basic/builtin_assign.js ! test/script/basic/builtinchain.js ! test/script/basic/calllink.js ! test/script/basic/closure.js ! test/script/basic/commandargs.js ! test/script/basic/compile-octane.js ! test/script/basic/condassign.js ! test/script/basic/construct.js ! test/script/basic/constructorname.js ! test/script/basic/date.js ! test/script/basic/dateparse.js ! test/script/basic/decinc.js ! test/script/basic/delete.js ! test/script/basic/delete2.js ! test/script/basic/dotpropname.js ! test/script/basic/doublecache.js ! test/script/basic/enumeration.js ! test/script/basic/errors.js ! test/script/basic/errorstack.js ! test/script/basic/eval.js ! test/script/basic/evalreturn.js ! test/script/basic/exprclosure.js ! test/script/basic/extensibility.js ! test/script/basic/fileline.js ! test/script/basic/finally-catchalls.js ! test/script/basic/finallyreturn.js ! test/script/basic/forin.js ! test/script/basic/forin2.js ! test/script/basic/funcarray.js ! test/script/basic/funcbind.js ! test/script/basic/funcconstructor.js ! test/script/basic/getclassname.js ! test/script/basic/getenv.js ! test/script/basic/getter_callsite.js ! test/script/basic/gettercalls.js ! test/script/basic/getterfunc.js ! test/script/basic/gettersetter.js ! test/script/basic/globalaccess.js ! test/script/basic/globals.js ! test/script/basic/globalscope.js ! test/script/basic/hello.js ! test/script/basic/herestr_operator.js ! test/script/basic/illegaljavaname.js ! test/script/basic/incheck.js ! test/script/basic/indexedcall.js ! test/script/basic/info.js ! test/script/basic/inherited_nonwritable.js ! test/script/basic/instanceof.js ! test/script/basic/instanceof2.js ! test/script/basic/interfaces.js ! test/script/basic/iterator.js ! test/script/basic/java.js ! test/script/basic/javaarray.js ! test/script/basic/javaarrayconversion.js ! test/script/basic/javaexceptions.js ! test/script/basic/javaimporter.js ! test/script/basic/javainnerclasses.js ! test/script/basic/javasigcall.js ! test/script/basic/jquery.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapterlink.js ! test/script/basic/json.js ! test/script/basic/list.js ! test/script/basic/literal.js ! test/script/basic/load.js ! test/script/basic/loadedfile.js ! test/script/basic/localundef.js ! test/script/basic/map.js ! test/script/basic/math.js ! test/script/basic/minuszero.js ! test/script/basic/module.js ! test/script/basic/moduleload.js ! test/script/basic/nashorn2.js ! test/script/basic/natives.js ! test/script/basic/new.js ! test/script/basic/newexpr.js ! test/script/basic/newnew.js ! test/script/basic/nonconstructors.js ! test/script/basic/nosuchmethod.js ! test/script/basic/nosuchproperty.js ! test/script/basic/number.js ! test/script/basic/numberstring.js ! test/script/basic/objectprops.js ! test/script/basic/objects.js ! test/script/basic/options.js ! test/script/basic/propchange.js ! test/script/basic/propertycheck.js ! test/script/basic/prototype.js ! test/script/basic/pushpull.js ! test/script/basic/regex.js ! test/script/basic/regexp_flags.js ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/basic/samfunc.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED ! test/script/basic/sealfreeze.js ! test/script/basic/setlength.js ! test/script/basic/stdin.js ! test/script/basic/strings.js ! test/script/basic/throws.js ! test/script/basic/tosource.js ! test/script/basic/tostring.js ! test/script/basic/try.js ! test/script/basic/trybreakcont.js ! test/script/basic/trycatch.js ! test/script/basic/trycatchfor.js ! test/script/basic/tryfinallyreturn.js ! test/script/basic/tryforbreak.js ! test/script/basic/typechange.js ! test/script/basic/typeof.js ! test/script/basic/typeof2.js ! test/script/basic/undefined.js ! test/script/basic/underscore.js ! test/script/basic/varargs.js ! test/script/basic/void.js ! test/script/basic/with.js ! test/script/basic/withprimitive.js ! test/script/basic/writable_relink.js ! test/script/basic/xorassign.js ! test/script/basic/yui.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js ! test/script/error/NASHORN-154/improper_return_break_continue.js ! test/script/error/NASHORN-154/invalid_lvalue.js ! test/script/error/NASHORN-154/literal_data_and_accessor.js ! test/script/error/NASHORN-154/literal_mult_getters.js ! test/script/error/NASHORN-154/literal_mult_prop_in_strict.js ! test/script/error/NASHORN-154/with_in_strict.js ! test/script/error/NASHORN-214.js ! test/script/error/NASHORN-35.js ! test/script/error/NASHORN-39.js ! test/script/error/NASHORN-568.js ! test/script/error/NASHORN-57.js ! test/script/error/NASHORN-668.js ! test/script/error/quotemissing.js ! test/script/error/strictmode.js ! test/script/representations/NASHORN-592a.js ! test/script/sandbox/NASHORN-525.js ! test/script/sandbox/classloader.js ! test/script/sandbox/doprivileged.js ! test/script/sandbox/exit.js ! test/script/sandbox/file.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/loadLibrary.js ! test/script/sandbox/net.js ! test/script/sandbox/property.js ! test/script/sandbox/reflection.js ! test/script/sandbox/runnable.js ! test/script/sandbox/unsafe.js ! test/script/test262.js ! test/script/test262_single.js ! test/src/UnnamedPackageTestCallback.java ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/api/scripting/WindowEventHandler.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/access/MethodAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberBoxingTest.java ! test/src/jdk/nashorn/internal/access/ObjectAccessTest.java ! test/src/jdk/nashorn/internal/access/Person.java ! test/src/jdk/nashorn/internal/access/SharedObject.java ! test/src/jdk/nashorn/internal/access/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/performance/AuroraWrapper.java ! test/src/jdk/nashorn/internal/performance/OctaneTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/performance/SplayTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java ! test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptTest.java ! test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java ! test/src/jdk/nashorn/internal/test/framework/TestHelper.java ! test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java ! test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java ! test/src/jdk/nashorn/internal/test/models/FinalClass.java ! test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java ! test/src/jdk/nashorn/internal/test/models/NonPublicClass.java ! test/src/jdk/nashorn/internal/test/models/OuterClass.java ! test/src/jdk/nashorn/internal/test/models/OverloadedSam.java ! test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: 1e3f411f47bf Author: lagergren Date: 2013-01-07 19:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1e3f411f47bf 8005789: Forgot to document -Dnashorn.unstable.relink.threshold Summary: Added documentation to DEVELOPER_README, fixed code convention warnings Reviewed-by: attila ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 41c7093477ae Author: jlaskey Date: 2013-01-07 14:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/41c7093477ae 8005703: Offsets miscalculated for blocks Reviewed-by: lagergren Contributed-by: petr.hejl at oracle.com ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: d14da0d0c577 Author: sundar Date: 2013-01-08 08:51 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d14da0d0c577 8005782: get rid of javadoc errors, warnings in nashorn build Reviewed-by: lagergren ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 0e7da548ef6a Author: lagergren Date: 2013-01-08 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0e7da548ef6a 8005788: Loggers and their corresponding system properties not working correctly Summary: 1-1 mapping now maintained. Used Context err instead of System.err in several places (after bootstrapping Context). Problematic closing of err stream replaced by @SuppressWarnings("resource") Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 5f2db2d8a7fa Author: sundar Date: 2013-01-08 15:02 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5f2db2d8a7fa 8005835: NASHORN-668 output fails to compare with the corresponding .EXPECTED file Reviewed-by: lagergren, hannesw ! test/script/error/NASHORN-668.js.EXPECTED Changeset: d8e4d66f1a06 Author: lagergren Date: 2013-01-08 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d8e4d66f1a06 8005843: refSymbols lookup of unbound variable could cause NullPointerException in Lower Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/NASHORN-837.js Changeset: c5a321205f49 Author: attila Date: 2013-01-08 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c5a321205f49 8005846: Remove Mangler in favor of Dynalink's NameCodec Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 4620ac94e7dc Author: attila Date: 2013-01-08 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4620ac94e7dc 8005801: Refactor findSetMethod Summary: findSetMethod() was a very large single method, very unreadable and unmaintainable. It was broken into easy-to-understand pieces. The refactoring required introduction of a comand-object like entity, SetMethodCreator, to contain the nontrivial transient state of the algorithm that made the original big method so resistant to refactoring in the first place. Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java - src/jdk/nashorn/internal/runtime/linker/Mangler.java Changeset: 69a4f0363d0f Author: lagergren Date: 2013-01-08 15:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/69a4f0363d0f 8005842: Loops in ASTWriter. Corrected @Reference and @Ignore node annotation for IR nodes Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 548587cfb065 Author: sundar Date: 2013-01-08 21:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/548587cfb065 8005848: assigning to global toString variable affects Object.prototype.toString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK_8005848.js Changeset: 812b9963b1c7 Author: attila Date: 2013-01-09 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/812b9963b1c7 8005777: Bug in the FacetIntrospector of Dynalink - non-public class should search super Reviewed-by: lagergren, sundar ! make/project.properties Changeset: 4cd65798ec70 Author: sundar Date: 2013-01-09 22:32 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4cd65798ec70 8005940: provide ant targets to get and update external test scripts Reviewed-by: jlaskey, lagergren ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! make/Makefile ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 9f59ba5090f2 Author: lagergren Date: 2013-01-10 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9f59ba5090f2 8005971: runsunspider.js should check results of benchmarks Reviewed-by: attila, hannesw ! test/script/basic/runsunspider.js Changeset: a7f177d6639c Author: sundar Date: 2013-01-10 19:03 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a7f177d6639c 8005987: ant octane tries to run non-benchmark scripts Reviewed-by: lagergren, attila, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 0362d36d3dd6 Author: sundar Date: 2013-01-10 19:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0362d36d3dd6 8005982: NASHORN-71.js failing in nightlys Reviewed-by: attila, lagergren, jlaskey ! test/script/basic/NASHORN-71.js - test/script/basic/NASHORN-71.js.EXPECTED Changeset: 2a5c2258827b Author: attila Date: 2013-01-10 15:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2a5c2258827b 8005983: JavaAdapterFactory generated proxy classes should take extra constructor arguments at the end Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED Changeset: 2a4769fcd13f Author: lagergren Date: 2013-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2a4769fcd13f 8005976: Break out AccessSpecializer into one pass before CodeGenerator instead of iterative applications from CodeGenerator Summary: Now scope and slot information is guaranteed to be fixed AND NOT CHANGE before CodeGeneration. We want to keep it that way to build future type specializations and bring all type work out of CodeGenerator. Reviewed-by: attila, hannesw + bin/dump_octane_code.sh ! bin/verbose_octane.sh ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f67bf56495ca Author: sundar Date: 2013-01-11 18:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f67bf56495ca 8006082: Provide option to run octane benchmarks in separate processes Reviewed-by: lagergren, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 8a5922638ff0 Author: sundar Date: 2013-01-11 20:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8a5922638ff0 8006093: Add a makefile target to run all tests (test, test262, perf tests) Reviewed-by: attila, hannesw ! make/Makefile ! make/build.xml Changeset: eda69555239a Author: attila Date: 2013-01-14 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eda69555239a 8006168: ability to generate multi-type Java adapters Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/DessertTopping.java + test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/internal/test/models/FloorWax.java + test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 3c6db5ea0ecc Author: sundar Date: 2013-01-14 21:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3c6db5ea0ecc 8006181: nashorn script engine does not run jrunscript's initialization script Reviewed-by: lagergren, jlaskey Contributed-by: rieberandreas at gmail.com + src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/api/scripting/resources/init.js Changeset: 1d0307c2bb4c Author: attila Date: 2013-01-15 13:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1d0307c2bb4c 8006293: Reduce ScriptObject.findCallMethodMethod Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java Changeset: ee73d7378e3e Author: attila Date: 2013-01-15 17:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ee73d7378e3e 8005958: invoking a function through INVOKESTATIC with more arguments than it declares resulted in malformed bytecode being generated Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8005958.js Changeset: 9088170e68df Author: attila Date: 2013-01-15 18:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9088170e68df 8006337: Discarded arguments for INVOKESTATIC must still be evaluated for side effects Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006337.js + test/script/basic/JDK-8006337.js.EXPECTED Changeset: 617313881c55 Author: jlaskey Date: 2013-01-16 07:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/617313881c55 8006304: Remove pre-population of maps for constructor produced maps Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + test/script/basic/JDK-8006304.js + test/script/basic/JDK-8006304.js.EXPECTED Changeset: 80447df16322 Author: sundar Date: 2013-01-16 17:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/80447df16322 8006412: Improve toString method of ScriptObjectMirror class Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cd5b684ce7b2 Author: sundar Date: 2013-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/cd5b684ce7b2 8006424: Passing null or undefined to adapter class constructors results in NPE or ClassCastException Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/basic/JDK-8006424.js Changeset: 4acebfe9e504 Author: jlaskey Date: 2013-01-17 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4acebfe9e504 8006517: PropertyHashMap.Element.equals() compares to Property Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java Changeset: f8136c060914 Author: sundar Date: 2013-01-18 08:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f8136c060914 8006527: nashorn jsr223 engine does not work in sandbox Reviewed-by: jlaskey, attila, lagergren + bin/nashornsecure + bin/nashornsecure.bat ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/sandbox/engine.js + test/script/sandbox/engine.js.EXPECTED + test/script/sandbox/jsadapter.js Changeset: 4361e8cd6a02 Author: sundar Date: 2013-01-18 17:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4361e8cd6a02 8006562: findOwnMH in nashorn "objects" package should be cleaned up Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: c887baec012a Author: sundar Date: 2013-01-19 09:14 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c887baec012a 8006584: improve variable handling in NashornScriptEngine Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a8966074d4e9 Author: sundar Date: 2013-01-19 22:35 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a8966074d4e9 8006557: JDK8/Lambda build clashes on Map.replace() Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 0cee498b330d Author: attila Date: 2013-01-21 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0cee498b330d 8006525: Give StaticClass objects their own linker Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 8b3cc4ad1810 Author: sundar Date: 2013-01-21 21:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8b3cc4ad1810 8006635: Reduce access levels as much as possible Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 935dcec38e9a Author: hannesw Date: 2013-01-22 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/935dcec38e9a 8006570: This-value for non-strict functions should be converted to object Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8006570.js + test/script/basic/JDK-8006570.js.EXPECTED Changeset: e43d1013d871 Author: attila Date: 2013-01-22 14:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e43d1013d871 8006677: Remove unused FunctionNode flags Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: e62dba3ce52b Author: sundar Date: 2013-01-22 22:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e62dba3ce52b 8006678: Avoid too many Context.getGlobal() calls Reviewed-by: lagergren, jlaskey ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 0dbcb7350595 Author: sundar Date: 2013-01-23 17:04 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0dbcb7350595 8006736: nashorn script engine should support the usage multiple global objects with same engine instance Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d4a968ca8953 Author: sundar Date: 2013-01-24 16:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d4a968ca8953 8006575: Error in codegen for element access on primitive value Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006575.js Changeset: 3f528769aee1 Author: sundar Date: 2013-01-24 17:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3f528769aee1 8006755: Functions inside with statements dont get correct scope Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8006755.js Changeset: edfa73d9fde7 Author: hannesw Date: 2013-01-24 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/edfa73d9fde7 8006408: Clean up and specialize NativeString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/examples/string-micro.js Changeset: f336aee22e85 Author: jlaskey Date: 2013-01-24 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f336aee22e85 8006852: Move tests from JIRA for prepopulated map failures Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8006852a.js + test/script/basic/JDK-8006852a.js.EXPECTED + test/script/basic/JDK-8006852b.js Changeset: bff7087396d7 Author: sundar Date: 2013-01-24 22:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bff7087396d7 8006857: ClassCastException when interface implementing function uses arguments object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8006857.js + test/script/basic/JDK-8006857.js.EXPECTED Changeset: f52d7294536f Author: hannesw Date: 2013-01-25 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f52d7294536f 8006766: Array-like access to characters of a string is slow Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: 8f7a86f82376 Author: sundar Date: 2013-01-28 18:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8f7a86f82376 8006983: Introduce a command line option to switch off syntactic extensions of nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8006983.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED Changeset: 265c46dbcf43 Author: sundar Date: 2013-01-28 21:29 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/265c46dbcf43 8007004: nashorn script engine should not use thread context class loader as script 'application loader' Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java Changeset: b6c69beebde6 Author: jlaskey Date: 2013-01-28 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b6c69beebde6 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! make/Makefile + makefiles/BuildNashorn.gmk + makefiles/Makefile Changeset: 333748665588 Author: sundar Date: 2013-01-29 19:57 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/333748665588 8007091: Provide private API to pass application class loader for nashorn script engine Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 755404d7d189 Author: jlaskey Date: 2013-01-29 14:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/755404d7d189 8007094: Apply version to nashorn.jar manifest Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 59970b70ebb5 Author: lagergren Date: 2013-01-30 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/59970b70ebb5 8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate ti ers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/b asic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila ! docs/DEVELOPER_README ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java - src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/FinalizeTypes.java + src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/access-specializer.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/typecoerce.js + test/script/basic/typecoerce.js.EXPECTED Changeset: ca6d5e4b8170 Author: sundar Date: 2013-01-30 17:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ca6d5e4b8170 8007132: Java objects returned from constructor functions are lost Reviewed-by: hannesw, lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8007132.js Changeset: 9f913c1843c8 Author: hannesw Date: 2013-01-30 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9f913c1843c8 8007109: Regression: String(ConsString) does not flatten argument to String Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/consstring.js + test/src/jdk/nashorn/internal/test/models/StringArgs.java Changeset: c04f54d5b672 Author: sundar Date: 2013-01-30 21:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c04f54d5b672 8007140: Java.extend crashes when attempting to extend java.lang.Object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8006424.js + test/script/basic/JDK-8007140.js Changeset: 9c1e7ae975db Author: sundar Date: 2013-01-31 20:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9c1e7ae975db 8007286: Add JavaAdapter and importPackage to compatibility script Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/importpackage.js + test/script/basic/javaadapter.js Changeset: f7825c1a11d3 Author: attila Date: 2013-01-31 18:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f7825c1a11d3 8006529: Methods always get callee - it should be conditional Summary: This commit streamlines the bytecode function signatures, prologue, local variable use, scope creation, and invocation. It started out quite innocently when we noticed that we always emit __callee__ parameters for all functions even when they are not needed, but it turned out to be quite a deep rabbit hole. In the end, I identified exact conditions when functions need to have a callee parameter, when they need to receive parent scope, when they need to create their own scope, when they need to have variable arity signature, and when they need to have an "arguments" object, and made sure that callee parameters in signatures only show up when they are needed, that parent function's scope is only passed to a child function when it is needed, that the function only creates its own scope when it is needed. In crypto.js, the number of scopes dropped from 446 to 244, and the number of callees dropped from 315 to 145. Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8006529-b.js + test/script/basic/JDK-8006529-b.js.EXPECTED + test/script/basic/JDK-8006529.js + test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 697f700d90c0 Author: hannesw Date: 2013-02-01 02:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/697f700d90c0 8007060: Primitive wrap filter throws ClassCastException in test262parallel Reviewed-by: sundar, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8007060.js + test/script/basic/JDK-8007060.js.EXPECTED Changeset: a704700470fb Author: jlaskey Date: 2013-02-04 08:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a704700470fb 8007455: Extraneous $(ECHO) in make/Makefile Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: bb86bf840f9f Author: attila Date: 2013-02-04 15:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bb86bf840f9f 8007460: var assignment to a parameter in a varargs method causes compilation error Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8007460.js + test/script/basic/JDK-8007460.js.EXPECTED Changeset: bee7c8a45a04 Author: lagergren Date: 2013-02-04 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bee7c8a45a04 8007215: Varargs broken for the case of passing more than the arg limit arguments. Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007215.js + test/script/basic/JDK-8007215.js.EXPECTED Changeset: 6f58c28c4faa Author: jlaskey Date: 2013-02-04 14:48 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6f58c28c4faa 8006191: `cmd` -> exec("cmd") in script mode Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8006191.js + test/script/basic/JDK-8006191.js.EXPECTED Changeset: 5c2ed5d89524 Author: sundar Date: 2013-02-05 09:11 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5c2ed5d89524 8007452: add scripting programmers doc changes for nashorn Reviewed-by: jlaskey, hannesw + docs/JavaScriptingProgrammersGuide.html + docs/source/EvalFile.java + docs/source/EvalScript.java + docs/source/InvokeScriptFunction.java + docs/source/InvokeScriptMethod.java + docs/source/MultiScopes.java + docs/source/RunnableImpl.java + docs/source/RunnableImplObject.java + docs/source/ScriptVars.java + docs/source/importpackageclass.js + docs/source/javaarray.js + docs/source/javaextend.js + docs/source/javaimporter.js + docs/source/javatypes.js + docs/source/overload.js + docs/source/runnable.js + docs/source/samfunc.js + docs/source/test.js ! src/jdk/nashorn/internal/objects/NativeJava.java Changeset: c48e8a28da90 Author: sundar Date: 2013-02-05 18:44 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c48e8a28da90 8007521: $ENV should be undefined when security manager is present Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java - test/script/basic/JDK-8006191.js - test/script/basic/JDK-8006191.js.EXPECTED + test/script/currently-failing/JDK-8006191.js + test/script/currently-failing/JDK-8006191.js.EXPECTED + test/script/sandbox/env.js + test/script/sandbox/exec.js Changeset: 819b5485949d Author: sundar Date: 2013-02-05 21:00 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/819b5485949d 8007522: IllegalStateException thrown from String.prototype.search function Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8007522.js Changeset: f05d4dae30f7 Author: sundar Date: 2013-02-05 22:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f05d4dae30f7 8007523: VerifyError on script that uses regular expression literals with ternary operator Reviewed-by: lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java ! test/script/basic/JDK-8007522.js + test/script/basic/JDK-8007523.js Changeset: f6fae6de6f4f Author: hannesw Date: 2013-02-06 10:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f6fae6de6f4f 8007273: Creation of ScriptFunctions can be refactored Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: fcf541418304 Author: sundar Date: 2013-02-06 17:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fcf541418304 8007619: Add support for deprecated properties of RegExp constructor Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007619.js + test/script/basic/JDK-8007619.js.EXPECTED Changeset: ec4d59c9b8d2 Author: jlaskey Date: 2013-02-06 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ec4d59c9b8d2 8007545: jjs input evalinput need to be NOT_ENUMERABLE Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/tools/resources/shell.js Changeset: 2ca25bf25d0c Author: jlaskey Date: 2013-02-06 11:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2ca25bf25d0c 8007629: Remove extraneous quit from shell.js Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/resources/shell.js Changeset: 02f810c26ff9 Author: jlaskey Date: 2013-02-06 12:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/02f810c26ff9 8007643: Add testing for quit and exit Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/sandbox/exit.js ! test/script/sandbox/exit.js.EXPECTED Changeset: d7e83be6e7aa Author: sundar Date: 2013-02-07 17:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d7e83be6e7aa 8007715: Make sure that not all tests run with AllPermission Reviewed-by: lagergren, attila ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/README - test/script/basic/JDK-8006424.js - test/script/basic/JDK-8006529.js - test/script/basic/NASHORN-638.js - test/script/basic/NASHORN-638.js.EXPECTED - test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-758.js - test/script/basic/getenv.js - test/script/basic/getenv.js.EXPECTED ! test/script/basic/javaexceptions.js ! test/script/basic/newexpr.js + test/script/sandbox/interfaceimpl.js + test/script/sandbox/loadcompat.js + test/script/trusted/JDK-8006424.js + test/script/trusted/JDK-8006529.js + test/script/trusted/NASHORN-638.js + test/script/trusted/NASHORN-638.js.EXPECTED + test/script/trusted/NASHORN-653.js + test/script/trusted/README + test/script/trusted/getenv.js + test/script/trusted/getenv.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: bca3a64a4a82 Author: hannesw Date: 2013-02-07 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bca3a64a4a82 8007627: Support @Getter annotation on constructor Reviewed-by: attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java Changeset: d5130a5803d1 Author: hannesw Date: 2013-02-07 15:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d5130a5803d1 8007718: Make static RegExp properties fully compatible to other engines Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007718.js + test/script/basic/JDK-8007718.js.EXPECTED Changeset: 8742be332c8a Author: jlaskey Date: 2013-02-08 09:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8742be332c8a 8006222: Move slot from SpillProperty to Property Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java Changeset: 5ead5333fa59 Author: attila Date: 2013-02-09 16:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5ead5333fa59 8006943: Fix order of function method arguments to be (callee, thisObject) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: abea4ba28901 Author: sundar Date: 2013-02-11 21:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/abea4ba28901 8007915: Nashorn IR, codegen, parser packages and Context instance should be inaccessible to user code Reviewed-by: lagergren, jlaskey, attila ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashornsecure ! bin/nashornsecure.bat ! make/Makefile ! make/build.xml + make/java.security.override ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java - src/jdk/nashorn/internal/parser/RegExp.java - src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/RegExp.java + src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/resources/parser.js + test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js + test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java + test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java + test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java + test/src/jdk/nashorn/api/javaaccess/Person.java + test/src/jdk/nashorn/api/javaaccess/SharedObject.java + test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java - test/src/jdk/nashorn/internal/access/BooleanAccessTest.java - test/src/jdk/nashorn/internal/access/MethodAccessTest.java - test/src/jdk/nashorn/internal/access/NumberAccessTest.java - test/src/jdk/nashorn/internal/access/NumberBoxingTest.java - test/src/jdk/nashorn/internal/access/ObjectAccessTest.java - test/src/jdk/nashorn/internal/access/Person.java - test/src/jdk/nashorn/internal/access/SharedObject.java - test/src/jdk/nashorn/internal/access/StringAccessTest.java - test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 774a0f349cc0 Author: hannesw Date: 2013-02-12 13:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/774a0f349cc0 8007956: Wrong or obsolete system properties in docs/DEVELOPER_README Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README Changeset: d50e1752f59b Author: attila Date: 2013-02-12 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d50e1752f59b 8007900: Function binding is inefficient Reviewed-by: jlaskey, lagergren + src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java + test/script/basic/funcbind2.js + test/script/basic/funcbind2.js.EXPECTED + test/script/basic/funcbind3.js + test/script/basic/funcbind3.js.EXPECTED Changeset: a3dc1b180ce7 Author: hannesw Date: 2013-02-13 13:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a3dc1b180ce7 8008096: TokenStream buffer should grow exponentially Reviewed-by: attila, lagergren, sundar ! src/jdk/nashorn/internal/parser/TokenStream.java Changeset: 38c44687e4bd Author: sundar Date: 2013-02-13 19:59 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/38c44687e4bd 8008103: Source object should maintain URL of the script source as a private field Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 222b9f32b674 Author: sundar Date: 2013-02-14 09:14 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/222b9f32b674 8008193: test262 tests should be run with security manager enabled Reviewed-by: jlaskey ! make/build.xml Changeset: 8c72a2bec1be Author: sundar Date: 2013-02-14 14:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8c72a2bec1be 8008197: Cross script engine function calls do not work as expected Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8008197.js ! test/script/basic/jquery.js Changeset: 43e32b36153c Author: lagergren Date: 2013-02-14 13:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/43e32b36153c 8008199: Lazy compilation and trampoline implementation Summary: The code pipeline now supports lazy compilation, which can be used to only compile certain FunctionNodes and leave others be, saving startup time. When these uncompiled nodes are hit, a trampoline will force them to be recompiled. This can also be used to specialize compilation fixing parameter types and return types to a callsite specific compilation. This will give performance. Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java - src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5a820fb11814 Author: attila Date: 2013-02-14 13:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5a820fb11814 8008085: Integrate Dynalink source code into Nashorn codebase Reviewed-by: jlaskey, lagergren, sundar ! THIRD_PARTY_README ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk/internal/dynalink/ChainedCallSite.java + src/jdk/internal/dynalink/DefaultBootstrapper.java + src/jdk/internal/dynalink/DynamicLinker.java + src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/MonomorphicCallSite.java + src/jdk/internal/dynalink/NoSuchDynamicMethodException.java + src/jdk/internal/dynalink/RelinkableCallSite.java + src/jdk/internal/dynalink/beans/AbstractJavaLinker.java + src/jdk/internal/dynalink/beans/AccessibleMembersLookup.java + src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/BeanIntrospector.java + src/jdk/internal/dynalink/beans/BeanLinker.java + src/jdk/internal/dynalink/beans/BeansLinker.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java + src/jdk/internal/dynalink/beans/ClassLinker.java + src/jdk/internal/dynalink/beans/ClassString.java + src/jdk/internal/dynalink/beans/DynamicMethod.java + src/jdk/internal/dynalink/beans/DynamicMethodLinker.java + src/jdk/internal/dynalink/beans/FacetIntrospector.java + src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java + src/jdk/internal/dynalink/beans/MaximallySpecific.java + src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/StaticClass.java + src/jdk/internal/dynalink/beans/StaticClassIntrospector.java + src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/messages.properties + src/jdk/internal/dynalink/beans/package.html + src/jdk/internal/dynalink/linker/ConversionComparator.java + src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk/internal/dynalink/linker/LinkRequest.java + src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/package.html + src/jdk/internal/dynalink/package.html + src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java + src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java + src/jdk/internal/dynalink/support/AutoDiscovery.java + src/jdk/internal/dynalink/support/Backport.java + src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java + src/jdk/internal/dynalink/support/ClassMap.java + src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java + src/jdk/internal/dynalink/support/Guards.java + src/jdk/internal/dynalink/support/LinkRequestImpl.java + src/jdk/internal/dynalink/support/LinkerServicesImpl.java + src/jdk/internal/dynalink/support/Lookup.java + src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java + src/jdk/internal/dynalink/support/NameCodec.java + src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk/internal/dynalink/support/TypeConverterFactory.java + src/jdk/internal/dynalink/support/TypeUtilities.java + src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/messages.properties + src/jdk/internal/dynalink/support/package.html ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! test/script/sandbox/nashorninternals.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: d086c3eead6b Author: lagergren Date: 2013-02-14 13:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d086c3eead6b 8008206: The allInteger case for SwitchNode generation in CodeGenerator assumes integer LITERALS only. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8008206.js + test/script/basic/JDK-8008206.js.EXPECTED Changeset: 3df0a0d62d60 Author: attila Date: 2013-02-14 13:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3df0a0d62d60 8007990: No access to interface methods on a restricted class Reviewed-by: jlaskey, lagergren, sundar ! make/build.xml + test/script/basic/JDK-8007990.js + test/script/basic/JDK-8007990.js.EXPECTED Changeset: d1ce4e09e4ba Author: hannesw Date: 2013-02-14 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d1ce4e09e4ba 8008198: java.lang.AssertionError: Invalid break target class jdk.nashorn.internal.ir.TryNode Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008198.js + test/script/basic/JDK-8008198.js.EXPECTED Changeset: d41d7cf9ab8b Author: jlaskey Date: 2013-02-14 11:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d41d7cf9ab8b 8008231: Fix build system to accommodate integration of dynalink Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 36065e5ea3d1 Author: hannesw Date: 2013-02-15 09:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/36065e5ea3d1 8008215: break in catch clause causes java.lang.VerifyError: Inconsistent stackmap Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008215.js + test/script/basic/JDK-8008215.js.EXPECTED Changeset: e478708faa22 Author: lagergren Date: 2013-02-15 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e478708faa22 8008239: Unpublicized parts of the code generator package that were only package internal. Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/Condition.java + src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/MapCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java - src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: 757a49aaad02 Author: sundar Date: 2013-02-15 18:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/757a49aaad02 8008291: Add more tests for better coverage of objects, scripting and parser packages Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/assign_builtin_func_props.js + test/script/basic/debugger.js + test/script/basic/yield.js ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 5851c5dac260 Author: sundar Date: 2013-02-15 20:40 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5851c5dac260 8008298: Add tests to cover specialized versions of Math functions. Reviewed-by: jlaskey, lagergren + test/script/basic/JDK-8008298.js Changeset: d5f74bd2dc20 Author: sundar Date: 2013-02-18 14:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d5f74bd2dc20 8008305: ScriptEngine.eval should offer the ability to provide a codebase Reviewed-by: lagergren, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/URLReader.java + test/script/trusted/JDK-8008305.js + test/script/trusted/JDK-8008305_subtest.js + test/script/trusted/urlreader.js Changeset: 3245e174fe3a Author: hannesw Date: 2013-02-18 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3245e174fe3a 8008351: Avoid using String.replace(String, String) in codegen Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java Changeset: f8221ce53c2e Author: attila Date: 2013-02-18 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f8221ce53c2e 8008371: Fix Dynalink compiler warnings and whitespace Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk/internal/dynalink/support/AutoDiscovery.java ! src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 4738de1bd57f Author: sundar Date: 2013-02-18 20:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4738de1bd57f 8008387: Improve code coverage tests for JSObjectLinker and NashornBottomLinker Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/javamethodcallerrors.js + test/script/basic/jsobject.js Changeset: b6798a83dbd4 Author: jlaskey Date: 2013-02-19 09:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b6798a83dbd4 8008420: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: b228e3cdbfc3 Author: jlaskey Date: 2013-02-19 09:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b228e3cdbfc3 Merge Changeset: b632446ba138 Author: sundar Date: 2013-02-19 20:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b632446ba138 8008448: Add coverage test for jdk.nashorn.internal.ir.debug.JSONWriter Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + test/script/basic/JDK-8008448.js Changeset: 58eea0e8f369 Author: sundar Date: 2013-02-20 17:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/58eea0e8f369 8008207: Make constants array and source fields private Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 671852e35ced Author: lagergren Date: 2013-02-20 16:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/671852e35ced 8008166: URL handling was broken on windows, causing "load" to malfunction Reviewed-by: attila, jlaskey Contributed-by: klara.ward at oracle.com ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java Changeset: a971adb68f38 Author: lagergren Date: 2013-02-21 16:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a971adb68f38 8008648: Lazy JIT scope and callee semantics bugfixes. Broke out wallclock timer. Reviewed-by: attila, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationException.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Timing.java ! test/script/trusted/JDK-8006529.js Changeset: ae1c9716685b Author: jlaskey Date: 2013-02-21 15:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ae1c9716685b 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: 678da59a29b3 Author: lagergren Date: 2013-02-22 08:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/678da59a29b3 8008554: load was broken for URLs Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8008554.js Changeset: 230a711062c1 Author: lagergren Date: 2013-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/230a711062c1 8008575: Re-integrate code coverage Reviewed-by: attila, hannesw Contributed-by: eugene.drobitko at oracle.com, ilya.dergalin at oracle.com ! make/build.xml + make/code_coverage.xml ! make/project.properties Changeset: 267cc4c85160 Author: lagergren Date: 2013-02-22 12:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/267cc4c85160 8007002: Replace implicit exception throwing methods with explicit throws - simplify control flow and remove useless code Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 3f0ff84aaf36 Author: jlaskey Date: 2013-02-22 10:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3f0ff84aaf36 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 508da3c7fc3a Author: hannesw Date: 2013-02-22 16:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/508da3c7fc3a 8008093: Make RegExp engine pluggable Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java - src/jdk/nashorn/internal/runtime/RegExp.java - src/jdk/nashorn/internal/runtime/RegExpMatch.java - src/jdk/nashorn/internal/runtime/RegExpScanner.java + src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/RegExpMatcher.java + src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java + src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: e42fd1640ff9 Author: hannesw Date: 2013-02-22 17:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e42fd1640ff9 8006028: Integrate Joni regexp engine with Nashorn Reviewed-by: lagergren, attila ! THIRD_PARTY_README ! docs/DEVELOPER_README + src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFold.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFoldArg.java + src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java + src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/Config.java + src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java + src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java + src/jdk/nashorn/internal/runtime/regexp/joni/MatcherFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/MinMaxLen.java + src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/NodeOptInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptAnchorInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptExactInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptMapInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/Option.java + src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + src/jdk/nashorn/internal/runtime/regexp/joni/Region.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java + src/jdk/nashorn/internal/runtime/regexp/joni/Token.java + src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java + src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java + src/jdk/nashorn/internal/runtime/regexp/joni/Warnings.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnchorNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnyCharNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AnchorType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Arguments.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AsmConstants.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCSTATE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCVALTYPE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/EncloseType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/MetaChar.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPSize.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/RegexState.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackPopLevel.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StringType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/SyntaxProperties.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TargetInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TokenType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Traverse.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/CharacterType.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/IntHolder.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/InternalException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/JOniException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/SyntaxException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java Changeset: 7f5b7c6859d7 Author: sundar Date: 2013-02-22 22:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7f5b7c6859d7 8008729: Make sure that we can run basic jsr223 tests using jtreg Reviewed-by: jlaskey, hannesw, lagergren + test/TEST.ROOT ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 5452f82eb2ce Author: jlaskey Date: 2013-02-22 23:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5452f82eb2ce 8008776: Revise BuildNashorn.gmk for changes in new build system Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 927fba6785b0 Author: sundar Date: 2013-02-25 16:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/927fba6785b0 8008731: Separate configuration environment (options, error/output writer etc.) from Context Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java - src/jdk/nashorn/internal/runtime/OptionsObject.java + src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5610ac25d8ff Author: sundar Date: 2013-02-25 18:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5610ac25d8ff 8008789: Enable java access and nashorn runtime tests for jtreg Reviewed-by: lagergren, jlaskey, hannesw ! make/build.xml ! test/TEST.ROOT ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 1654918e0612 Author: attila Date: 2013-02-25 16:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1654918e0612 8006984: Introducing local into a function inside with statement confuses its scope Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8006984.js + test/script/basic/JDK-8006984.js.EXPECTED Changeset: a90094ae5be3 Author: sundar Date: 2013-02-26 22:57 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a90094ae5be3 8009021: nasgen should be run on boot jdk rather than currenly built jdk Reviewed-by: jlaskey ! makefiles/BuildNashorn.gmk Changeset: 1d3dca059b3e Author: alanb Date: 2013-02-27 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1d3dca059b3e 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Reviewed-by: chegar, sundar ! makefiles/BuildNashorn.gmk Changeset: 071e859b371e Author: attila Date: 2013-02-27 15:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/071e859b371e 8009143: Eliminate Dynalink dependency on java.beans Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java Changeset: 928ea3d8faf0 Author: attila Date: 2013-02-27 15:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/928ea3d8faf0 8009146: Eliminate some dead code in preparation for immutable AST Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: 1da9e37697f6 Author: attila Date: 2013-02-27 16:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1da9e37697f6 8009150: Previous dead code elimination was incomplete Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/BinaryNode.java Changeset: 1e03be240534 Author: sundar Date: 2013-02-28 20:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1e03be240534 8009229: ant makefile default target should be "test" Reviewed-by: lagergren, jlaskey ! make/build.xml Changeset: 037e1de7ab1a Author: hannesw Date: 2013-02-28 22:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/037e1de7ab1a 8009240: RegExpScanner code is inefficient and too complex Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 7e9fbe621d87 Author: sundar Date: 2013-03-01 15:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7e9fbe621d87 8009263: Fix all javadoc errors in nashorn code Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java Changeset: 3b222c90b7de Author: jlaskey Date: 2013-03-02 11:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3b222c90b7de Merge Changeset: f90810d79b57 Author: hannesw Date: 2013-03-04 11:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f90810d79b57 8008370: coffee script compiler doesn't work with Nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8008370.js + test/script/basic/JDK-8008370.js.EXPECTED Changeset: fe5211fc3114 Author: jlaskey Date: 2013-03-04 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fe5211fc3114 8009379: Remove $ from generated class names Reviewed-by: attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java - src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JO.java - src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/internal/scripts/JS.java Changeset: 3d57f57acd9c Author: sundar Date: 2013-03-06 22:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3d57f57acd9c 8009553: Object.create(Array.prototype) doesn't respect reset length Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8009553.js Changeset: 5759f600fcf7 Author: sundar Date: 2013-03-09 21:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5759f600fcf7 8009559: clean up method handle lookup code. Reviewed-by: ahgross, jlaskey, attila, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/java.security.override ! src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java - src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SafeUnreflector.java + src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java + src/jdk/internal/dynalink/beans/SandboxClassLoader.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/sandbox/Unreflector.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/lookup/Lookup.java + src/jdk/nashorn/internal/lookup/MethodHandleFactory.java + src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - src/jdk/nashorn/internal/runtime/linker/Lookup.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/currently-failing/JDK-8006529.js - test/script/trusted/JDK-8006529.js Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags From john.coomes at oracle.com Thu Mar 21 21:58:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 04:58:34 +0000 Subject: hg: hsx/hotspot-main/langtools: 58 new changesets Message-ID: <20130322050114.60E6448311@hg.openjdk.java.net> Changeset: 58289451d9ed Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/58289451d9ed Added tag jdk8-b81 for changeset ed69d087fdfd ! .hgtags Changeset: 63872da94576 Author: darcy Date: 2013-02-13 23:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/63872da94576 8001457: New tests needed for library-side changes for repeating annotations Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java Changeset: 88286a36bb34 Author: mchung Date: 2013-02-14 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/88286a36bb34 8006225: tools/jdeps/Basic.java failes with AssertionError Reviewed-by: alanb + src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! test/tools/jdeps/Basic.java Changeset: 040f02711b73 Author: jjg Date: 2013-02-15 08:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/040f02711b73 8007052: javap should include the descriptor for a method in verbose mode Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/DescriptorTest.java Changeset: 0baaae675b19 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0baaae675b19 8006749: compiler does not allow Object protected methods to be used in lambda Summary: Check.checkFunctionalInterface should take into account 'fake' override Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/LambdaConv26.java Changeset: f6e667f52af4 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f6e667f52af4 8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract Summary: Missing abstractness check on super rmethod references Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReference62.java + test/tools/javac/lambda/MethodReference62.out Changeset: 4ff468de829d Author: mcimadamore Date: 2013-02-15 16:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4ff468de829d 8007462: Fix provisional applicability for method references Summary: Add speculative arity-based check to rule out potential candidates when stuck reference is passed to method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.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/IncompatibleArgTypesInMethodRef.java + test/tools/javac/lambda/TargetType60.java + test/tools/javac/lambda/TargetType60.out Changeset: 3cd997b9fd84 Author: mcimadamore Date: 2013-02-15 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3cd997b9fd84 8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures Summary: Bad check in Types.interfaceCandidates Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/FunctionalInterfaceAnno02.java Changeset: 186023614cd3 Author: mcimadamore Date: 2013-02-15 16:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/186023614cd3 8007427: Annotation element as '_' gives compiler error instead of a warning 8007401: Write test to check for generation of warnings when '_' is used as an identifier Summary: Extended identifier production not used in annotation values Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/lambda/IdentifierTest.java + test/tools/javac/lambda/IdentifierTest.out Changeset: 258c72fa7fa2 Author: mcimadamore Date: 2013-02-15 16:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/258c72fa7fa2 Merge Changeset: da2f7dd53915 Author: mcimadamore Date: 2013-02-15 18:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/da2f7dd53915 8008309: TargetType60 fails because of bad golden file Summary: bad golden file Reviewed-by: jjg ! test/tools/javac/lambda/TargetType60.out Changeset: 9fb4f223a90d Author: jjg Date: 2013-02-15 11:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9fb4f223a90d 8008313: 8007052 breaks test/tools/javap/MethodParameters.java Reviewed-by: darcy ! test/tools/javap/MethodParameters.java Changeset: f1f605f85850 Author: rfield Date: 2013-02-15 18:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f1f605f85850 8004969: Generate $deserializeLambda$ method 8006763: super in method reference used in anonymous class - ClassFormatError is produced 8005632: Inner classes within lambdas cause build failures 8005653: Lambdas containing inner classes referencing external type variables do not correctly parameterize the inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/lambda/LambdaInnerTypeVarArgs.java + test/tools/javac/lambda/LambdaInnerTypeVarReflect.java + test/tools/javac/lambda/MethodReference61.java Changeset: 2620c953e9fe Author: vromero Date: 2013-02-18 14:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2620c953e9fe 6563143: javac should issue a warning for overriding equals without hashCode Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out ! test/tools/javac/diags/examples.not-yet.txt Changeset: 87884cd0fea3 Author: jjg Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/87884cd0fea3 8008339: Test TargetAnnoCombo.java is broken Reviewed-by: jjh ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java Changeset: 011cf7e0a148 Author: darcy Date: 2013-02-19 00:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/011cf7e0a148 8008267: Add @Supported annotation to com.sun.source types Reviewed-by: jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/Server.java Changeset: dc8b7aa7cef3 Author: vromero Date: 2013-02-19 17:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dc8b7aa7cef3 8006212: javac, convert jtreg tests from shell script to java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java + test/tools/apt/Basics/CheckAptIsRemovedTest.java - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh + test/tools/javac/4846262/CheckEBCDICLocaleTest.java - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java - test/tools/javac/6302184/T6302184.sh + test/tools/javac/ClassPathTest/ClassPathTest.java - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java + test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh + test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java + test/tools/javac/T5090006/AssertionFailureTest.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh + test/tools/javac/constDebug/ConstDebugTest.java - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh + test/tools/javac/fatalErrors/NoJavaLangTest.java - test/tools/javac/innerClassFile/Driver.sh + test/tools/javac/innerClassFile/InnerClassFileTest.java - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java + test/tools/javac/javazip/JavaZipTest.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java + test/tools/javac/lib/ToolBox.java + test/tools/javac/links/LinksTest.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh + test/tools/javac/newlines/NewLineTest.java - test/tools/javac/newlines/Newlines.sh + test/tools/javac/stackmap/StackMapTest.java - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.java - test/tools/javac/unicode/SupplementaryJavaID6.sh + test/tools/javah/6257087/T6257087.java - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java + test/tools/javah/T4942232/MissingParamClassTest.java + test/tools/javah/constMacroTest/ConstMacroTest.java + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java + test/tools/javap/4866831/PublicInterfaceTest.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh + test/tools/javap/stackmap/StackmapTest.java - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 9345394ac8fe Author: ksrini Date: 2013-02-19 17:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9345394ac8fe 8006948: Update javac for MethodParameters format change Reviewed-by: ksrini, forax Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 4cf6e84f844f Author: lana Date: 2013-02-19 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4cf6e84f844f Merge Changeset: 267225edc1fe Author: strarup Date: 2013-02-20 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/267225edc1fe 8006582: Test for parameter names feature Reviewed-by: jjg, darcy, emc - test/tools/javac/MethodParameters.java + test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AttributeVisitor.java + test/tools/javac/MethodParameters/ClassFileVisitor.java + test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/Tester.java + test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParametersTest.java Changeset: d686d8a7eb78 Author: mcimadamore Date: 2013-02-21 15:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d686d8a7eb78 8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaConv27.java Changeset: 3a39d123d33a Author: mcimadamore Date: 2013-02-21 15:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3a39d123d33a 8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply Summary: DiagnosticFilter used during speculative attribution is too broad Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/lambda/speculative/MissingError.java + test/tools/javac/lambda/speculative/MissingError.out Changeset: f4fdd53f8b3e Author: mcimadamore Date: 2013-02-21 15:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f4fdd53f8b3e 8005183: Missing accessor for constructor reference pointing to private inner class ctor Summary: Compiler should add bridges when translating private constructor reference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference63.java Changeset: 7ac9242d2ca6 Author: mcimadamore Date: 2013-02-21 15:25 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7ac9242d2ca6 8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/TargetType64.java Changeset: 9f0ec00514b6 Author: mcimadamore Date: 2013-02-21 15:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9f0ec00514b6 8007461: Regression: bad overload resolution when inner class and outer class have method with same name Summary: Fix regression in varargs method resolution introduced by bad refactoring Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 3fef0cae83b3 Author: mcimadamore Date: 2013-02-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3fef0cae83b3 8008444: Inherited generic functional descriptors are merged incorrectly Summary: Missing call to Types.createMethodWithThrownTypes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv25.java + test/tools/javac/lambda/LambdaConv25.out Changeset: cd7340a84bb8 Author: rfield Date: 2013-02-21 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cd7340a84bb8 8008405: Now that metafactory is in place, add javac lambda serialization tests Summary: Tests part of original langtools serialization review. Reviewed-by: mcimadamore + test/tools/javac/T8004969.java + test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java + test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java Changeset: dabb36173c63 Author: ksrini Date: 2013-02-21 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dabb36173c63 8008658: Four new method param jtreg tests fail in nightly tests Reviewed-by: jjg, ksrini, mcimadamore Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java Changeset: 6118072811e5 Author: lana Date: 2013-02-21 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6118072811e5 Merge ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 8e82e4f225e4 Author: mcimadamore Date: 2013-02-22 13:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8e82e4f225e4 8008337: Write test to check for compiler error when static method in interface is called via super() Reviewed-by: mcimadamore Contributed-by: sonali.goel at oracle.com + test/tools/javac/lambda/StaticMethodNegTest.java + test/tools/javac/lambda/StaticMethodNegTest.out Changeset: 94e67bed460d Author: mcimadamore Date: 2013-02-22 18:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/94e67bed460d 8008708: Regression: separate compilation causes crash in wildcards inference logic Summary: Invalid use of WildcardType.bound in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/separate/Foo.java + test/tools/javac/lambda/separate/Test.java Changeset: ccbe7ffdd867 Author: jjg Date: 2013-02-24 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ccbe7ffdd867 7112427: The doclet needs to be able to generate JavaFX documentation. Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/PropertyWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertyGetterTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertySetterTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java + test/com/sun/javadoc/testJavaFX/C.java + test/com/sun/javadoc/testJavaFX/D.java + test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java Changeset: bd49e0304281 Author: vromero Date: 2013-02-26 09:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bd49e0304281 8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 133a0a0c2cbc Author: mcimadamore Date: 2013-02-28 14:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/133a0a0c2cbc 8008723: Graph Inference: bad graph calculation leads to assertion error Summary: Dependencies are not propagated correctly through merged nodes during inference graph initialization Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/lambda/TargetType65.java Changeset: 332f23993353 Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/332f23993353 8008813: Structural most specific fails when method reference is passed to overloaded method Summary: Bad logic for checking most specific method reference type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MostSpecific08.java Changeset: 08782b8b03ce Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/08782b8b03ce 8008537: Missing method reference lookup error when unbound search finds a static method Summary: Static-ness check should be applied after member reference resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.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/NonStaticCantBeRefFragment.java + test/tools/javac/diags/examples/StaticMethodInUnboundLookup.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference28.out ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt Changeset: 69cd2bfd4a31 Author: mcimadamore Date: 2013-03-05 14:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/69cd2bfd4a31 8004962: Code generation crash with lambda and local classes Summary: Translation info should be propagated from LambdaToMethod to Lower Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/lambda/LambdaCapture07.java Changeset: d2a98dde7ecc Author: mcimadamore Date: 2013-03-05 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d2a98dde7ecc 8009227: Certain diagnostics should not be deferred Summary: Add new diagnostic flag to mark non deferrable diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/lambda/abort/CompletionFailure.java Changeset: a708c5f1da06 Author: mcimadamore Date: 2013-03-05 14:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a708c5f1da06 8009154: Missing cast in method reference bridge leads to NoSuchMethodError Summary: Missing cast in generated method reference bridge Reviewed-by: rfield, jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference65.java Changeset: 12202e6ab78a Author: mcimadamore Date: 2013-03-05 14:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/12202e6ab78a 8009129: Illegal access error when calling method reference Summary: Javac generates method handle referencing non public type Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/NotDefPublicCantAccessFragment.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/p/C.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out + test/tools/javac/lambda/inaccessibleMref01/p1/C.java + test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java + test/tools/javac/lambda/inaccessibleMref02/p1/C.java Changeset: 188a07a0a7a0 Author: lana Date: 2013-03-05 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/188a07a0a7a0 Merge Changeset: d0178bd8125c Author: mcimadamore Date: 2013-03-06 15:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d0178bd8125c 8009299: Javac crashes when compiling method reference to static interface method Summary: Assertion in Check.checMethod is too strict Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/MethodReference66.java Changeset: 8a78243291ef Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8a78243291ef 8009459: Wrong behavior of diamond finder with source level 7 Summary: Diamond finder doesn't take into account different inference behaviors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6939780/T6939780.java + test/tools/javac/generics/diamond/6939780/T6939780_7.out + test/tools/javac/generics/diamond/6939780/T6939780_8.out - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out Changeset: c98b3e96c726 Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c98b3e96c726 8009391: Synthetic name of serializable lambda methods should not contain negative numbers Summary: Use hex representation of method signature hashcode to avoid negative numbers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: 3806171b52d8 Author: vromero Date: 2013-03-07 10:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3806171b52d8 8009138: javac, equals-hashCode warning tuning Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6563143/EqualsHashCodeWarningTest.java + test/tools/javac/6563143/EqualsHashCodeWarningTest.out - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 823fb9229724 Author: vromero Date: 2013-03-07 10:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/823fb9229724 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java + test/tools/javac/8009170/RedundantByteCodeInArrayTest.java Changeset: a02c3ddc182b Author: rfield Date: 2013-03-07 08:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a02c3ddc182b 8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/GenericMethodRefImplClass.java Changeset: c61add6bf8ac Author: vromero Date: 2013-03-11 15:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c61add6bf8ac 6181889: Empty try/finally results in bytecodes being generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6181889/EmptyFinallyTest.java Changeset: d0ae21e3a382 Author: rfield Date: 2013-03-11 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d0ae21e3a382 8009742: Bad lambda name for lambda in a static initializer or ctor Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/SerializedLambdaInInit.java Changeset: fbb6e470079d Author: ohrstrom Date: 2013-03-11 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fbb6e470079d 8009843: sjavac should accept -cp as synonym for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/Main.java Changeset: 7fe9b9d29095 Author: jfranck Date: 2013-03-12 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7fe9b9d29095 8005205: tests missing bugid for repeating annotation change Reviewed-by: jjg, ssides ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java Changeset: 6db9a3b1a93f Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6db9a3b1a93f 8008540: Constructor reference to non-reifiable array should be rejected 8008539: Spurious error when constructor reference mention an interface type 8008538: Constructor reference accepts wildcard parameterized types Summary: Overhaul of Check.checkConstructorRefType Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference64.java + test/tools/javac/lambda/MethodReference64.out Changeset: 5ddecb91d843 Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5ddecb91d843 8009545: Graph inference: dependencies between inference variables should be set during incorporation Summary: Move all transitivity checks into the incorporation round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out Changeset: f427043f8c65 Author: jfranck Date: 2013-03-12 17:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f427043f8c65 7196531: Duplicate error messages on repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out Changeset: 39f8eb897ec6 Author: lana Date: 2013-03-12 16:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/39f8eb897ec6 Merge - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh - test/tools/javac/6302184/T6302184.sh - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MethodParameters.java - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out - test/tools/javac/innerClassFile/Driver.sh - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh - test/tools/javac/newlines/Newlines.sh - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh - test/tools/javac/unicode/SupplementaryJavaID6.sh - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 825da6847791 Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/825da6847791 Merge Changeset: 22ba3f92d4ae Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags From joel.franck at oracle.com Fri Mar 22 07:16:09 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 22 Mar 2013 15:16:09 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations Message-ID: <514C67A9.1060106@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.01/ Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009382 In short, this is needed in order to implement the desired semantics for reflecting over type annotations after a class redefine. This is also needed in order to reduce the size overhead introduces on the JDK side in the current type annotations reflection implementation. A prototype of the jdk changes can be found here: http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ While in the neighborhood I also fixed a handful of unlikely but possible null dereferences and removed an unused resource mark. I have run jdk_lang on a fastdebug build to verify the removal of the resource mark in addition to manual verification (also Dan helped me look into this, but errors are mine). For Oracle reviewers, ccc is approved. testing done: jdk_lang with and without my prototype jdk changes x product/fastdebug vm.quick.testlist jprt standard build and test cheers /Joel From christian.thalinger at oracle.com Fri Mar 22 10:27:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Mar 2013 10:27:23 -0700 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <514C67A9.1060106@oracle.com> References: <514C67A9.1060106@oracle.com> Message-ID: <26A4FFCE-DB9F-4F19-BF3C-0C2A0231D608@oracle.com> On Mar 22, 2013, at 7:16 AM, Joel Borggr?n-Franck wrote: > Hi, > > Please review: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.01/ > > Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009382 > > In short, this is needed in order to implement the desired semantics for reflecting over type annotations after a class redefine. This is also needed in order to reduce the size overhead introduces on the JDK side in the current type annotations reflection implementation. > > A prototype of the jdk changes can be found here: http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ Can we not called them foo0? That trailing 0 doesn't give any value. -- Chris > > While in the neighborhood I also fixed a handful of unlikely but possible null dereferences and removed an unused resource mark. I have run jdk_lang on a fastdebug build to verify the removal of the resource mark in addition to manual verification (also Dan helped me look into this, but errors are mine). > > For Oracle reviewers, ccc is approved. > > testing done: > > jdk_lang with and without my prototype jdk changes x product/fastdebug > vm.quick.testlist > jprt standard build and test > > cheers > /Joel From morris.meyer at oracle.com Fri Mar 22 12:25:44 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Fri, 22 Mar 2013 19:25:44 +0000 Subject: hg: hsx/hotspot-main/hotspot: 27 new changesets Message-ID: <20130322192642.6E9524834D@hg.openjdk.java.net> Changeset: 9960dce2024f Author: kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author: kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author: morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b4ce9870fd6 8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp Summary: add guarantee() to add_generation_memory_pool() Reviewed-by: kvn, twisti ! src/share/vm/services/memoryService.cpp Changeset: 0a2deac0bbfb Author: morris Date: 2013-03-16 07:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0a2deac0bbfb 8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp Summary: add guarantee() to oop_result inlines Reviewed-by: kvn, twisti ! src/cpu/x86/vm/frame_x86.inline.hpp Changeset: 9ef47379df20 Author: morris Date: 2013-03-16 07:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ef47379df20 8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Summary: add null check to signal handler Reviewed-by: dcubed ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 8552f0992748 Author: kmo Date: 2013-03-15 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8552f0992748 8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers Reviewed-by: coleenp, roland Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java Changeset: 592f9722c72e Author: kmo Date: 2013-03-16 21:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/592f9722c72e Merge Changeset: 4efac99a998b Author: iignatyev Date: 2013-03-18 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4efac99a998b 8008211: Some of WB tests on compiler fail Reviewed-by: kvn, vlivanov ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: a5de0cc2f91c Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a5de0cc2f91c 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 578d9044c463 Author: roland Date: 2013-03-18 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/578d9044c463 Merge Changeset: be4d5c6c1f79 Author: neliasso Date: 2013-03-19 10:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be4d5c6c1f79 8010121: Remove definition of ShouldNotReachHere2(msg) Reviewed-by: kvn, stefank, rbackman, twisti Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: f15df3af32c5 Author: morris Date: 2013-03-19 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f15df3af32c5 8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp Summary: add guarantee() to DoScheduling() Reviewed-by: twisti, kvn ! src/share/vm/opto/output.cpp Changeset: 75a28f465a12 Author: morris Date: 2013-03-19 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/75a28f465a12 8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: add NULL checks for compiler name Reviewed-by: twisti, kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 80208f353616 Author: kvn Date: 2013-03-19 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/80208f353616 8010222: 8007439 disabled inlining of cold accessor methods Summary: added missing parenthesis Reviewed-by: jrose ! src/share/vm/opto/bytecodeInfo.cpp Changeset: 2eef6d34833b Author: morris Date: 2013-03-19 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2eef6d34833b 8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp Summary: add guarantee() checks to merge_state_into_bb() Reviewed-by: kvn ! src/share/vm/oops/generateOopMap.cpp Changeset: 3b9368710f08 Author: morris Date: 2013-03-19 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b9368710f08 8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp Summary: add guarantee() checks Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 1275835a4ccc Author: morris Date: 2013-03-19 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1275835a4ccc Merge Changeset: 41340544e182 Author: morris Date: 2013-03-20 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41340544e182 8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp Summary: add guarantee() to set_to_interpreted() Reviewed-by: kvn ! src/share/vm/code/compiledIC.cpp Changeset: 2dec1d9bfbe1 Author: morris Date: 2013-03-20 06:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2dec1d9bfbe1 8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp Summary: add guarantee() to get_instance_klass_for_declared_method_holder() Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp Changeset: 653d0346aa80 Author: morris Date: 2013-03-20 06:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/653d0346aa80 8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp Summary: add guarantee() to disqualify_method() Reviewed-by: kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: a59625d96f71 Author: morris Date: 2013-03-20 07:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a59625d96f71 8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp Summary: add guarantee() to insert_pre_post_loops() Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 98f3af397705 Author: twisti Date: 2013-03-20 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98f3af397705 8006965: remove test_gamma and add dedicated test_* targets instead Reviewed-by: kvn, jcoomes ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make - make/test/Queens.java Changeset: 589aa23334ea Author: morris Date: 2013-03-21 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/589aa23334ea 8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp Summary: added guarantee() to pd_address_in_code() Reviewed-by: kvn ! src/cpu/x86/vm/relocInfo_x86.cpp Changeset: c3c64a973559 Author: morris Date: 2013-03-21 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c3c64a973559 8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp Summary: added guarantee() to print_entry_on() Reviewed-by: kvn ! src/share/vm/oops/constantPool.cpp Changeset: 3536ea6bc4df Author: morris Date: 2013-03-21 21:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3536ea6bc4df Merge - make/test/Queens.java From christian.thalinger at oracle.com Fri Mar 22 16:10:03 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Mar 2013 16:10:03 -0700 Subject: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK In-Reply-To: <7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com> References: <253908D1-82B4-407D-A7B5-505184C0FE0E@oracle.com> <7D0554D4-7E1E-4DD0-907A-8F7AF17B9928@oracle.com> Message-ID: <8C82BDFA-7981-4D0C-955A-D9C474831DF2@oracle.com> On Mar 19, 2013, at 6:02 PM, Christian Thalinger wrote: > > On Mar 19, 2013, at 5:21 PM, John Rose wrote: > >> On Mar 14, 2013, at 8:31 PM, Christian Thalinger wrote: >> >>> [This is the HotSpot part of JEP 176] >>> >>> http://cr.openjdk.java.net/~twisti/7198429 >>> >>> 7198429: need checked categorization of caller-sensitive methods in the JDK >>> Reviewed-by: >> >> >> Over all, great work on a tricky problem. I'd add a few asserts and tweak a couple of lines; see below. Reviewed as is or with suggested changes. ? John >> >> --- Method::is_ignored_by_security_stack_walk >> I would like to see reflect_invoke_cache go away some day. Would it be possible to strengthen the asserts to prove that it is an expensive alias for an intrinsic_id check? (I realize this is a question mainly for folks working on JVMTI.) > > That's what I tried to do: if the intrinsic_id == _invoke it also must be the same method in reflect_invoke_cache. More than that would mean to enhance ActiveMethodOopsCache because you can't ask for methods in the cache. > >> >> --- JVM_GetCallerClass >> Suggest an assert for vfst.method() == NULL. Should not happen, and previous code would apparently have crashed already, but... >> >> (The corner case I'm thinking of is a compiled frame with nmethod::method returning null after nmethod::make_unloaded. Should not happen.) > > Sure, I can add that assert but there is other code in jvm.cpp that relies on the fact that vfst.method() is non-null. We should add asserts in all that places but that's for another RFE. > >> >> --- JVM_GetClassContext >> What do these lines do: >> + // Collect method holders >> + GrowableArray* klass_array = new GrowableArray(); >> >> It looks like a paste-o from another source base. > > Left over. I filed an RFE for that improvement: > > JDK-8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink > >> >> --- LibraryCallKit::inline_native_Reflection_getCallerClass >> >> I believe this assertion, but I would prefer to see it checked more forcibly: >> + // NOTE: Start the loop at depth 1 because the current JVM state does >> + // not include the Reflection.getCallerClass() frame. >> >> Not sure there is a good way to do this. But, perhaps put the comment here: >> case 0: >> // ...comment... >> ShouldNotReachHere(); > > How about: > > case 0: > fatal("current JVM state does not include the Reflection.getCallerClass() frame"); > break; > >> >> Also, if something goes wrong with caller sensitivity, we just get a "return false". Perhaps do a "caller_jvm=NULL;break" to branch to the pretty failure message? That makes it slightly easier to see what happened. > > It seems easier to add printing code to the case statement: > > case 1: > // Frame 0 and 1 must be caller sensitive (see JVM_GetCallerClass). > if (!m->caller_sensitive()) { > #ifndef PRODUCT > if ((PrintIntrinsics || PrintInlining || PrintOptoInlining) && Verbose) { > tty->print_cr(" Bailing out: CallerSensitive annotation expected at frame %d", n); > } > #endif > return false; // bail-out; let JVM_GetCallerClass do the work > } > break; > >> >> The LogCompilation switch should leave a "paper trail". Actually, I see that LogCompilation doesn't mention failed intrinsic inlines. Rats. At least PrintInlining or PrintIntrinsics (diagnostic flags) will give us some leverage if we need to debug. >> >> --- JVM_RegisterUnsafeMethods >> That's an improvement. Thanks. >> >> (A nagging worry: How big are those static tables getting?) > > We could remove some very old ones like 1.4.0 and 1.4.1. This time, next time? > >> >> --- vframeStreamCommon::security_get_caller_frame >> This now does something odd if depth < 0. Suggest an assert. > > The behavior with depth < 0 in the current code is even worse. An assert is a good idea. As discussed I want to remove that method in the future because its uses are dubious. I forgot to update the webrev. Here you go: http://cr.openjdk.java.net/~twisti/7198429/ -- Chris From stefan.karlsson at oracle.com Fri Mar 22 16:42:12 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 22 Mar 2013 23:42:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20130322234232.0DCCA48364@hg.openjdk.java.net> Changeset: 79af1312fc2c Author: mgerdin Date: 2013-03-14 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79af1312fc2c 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap Reviewed-by: jmasa, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp Changeset: 3c226052f7dc Author: tschatzl Date: 2013-03-14 09:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c226052f7dc 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Summary: Use the correct collector to retrieve accumulated gen1 trace time Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp Changeset: 19f9fabd94cc Author: stefank Date: 2013-03-18 09:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19f9fabd94cc Merge ! src/share/vm/memory/metaspace.cpp Changeset: fa08949fe0cb Author: johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: e864cc14ca75 Author: johnc Date: 2013-03-19 00:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e864cc14ca75 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 1179172e9ec9 Author: johnc Date: 2013-03-19 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1179172e9ec9 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 7f0cb32dd233 Author: mgerdin Date: 2013-03-21 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f0cb32dd233 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity" Reviewed-by: jmasa, johnc ! src/share/vm/memory/metaspace.cpp Changeset: 47902e9acb3a Author: stefank Date: 2013-03-22 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/47902e9acb3a Merge ! src/share/vm/memory/metaspace.cpp Changeset: 5855e849c7e6 Author: stefank Date: 2013-03-22 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5855e849c7e6 Merge From alejandro.murillo at oracle.com Fri Mar 22 21:10:08 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Mar 2013 04:10:08 +0000 Subject: hg: hsx/hsx24/hotspot: 8010497: new hotspot build - hs24-b38 Message-ID: <20130323041020.AC0B14836C@hg.openjdk.java.net> Changeset: 9e372c67c5eb Author: amurillo Date: 2013-03-21 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9e372c67c5eb 8010497: new hotspot build - hs24-b38 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.danushevsky at oracle.com Sat Mar 23 01:36:42 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Sat, 23 Mar 2013 08:36:42 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130323083656.5880348372@hg.openjdk.java.net> Changeset: 499ccc15bbc8 Author: bpittore Date: 2013-03-15 15:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/499ccc15bbc8 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp Changeset: 9e62e72c59cc Author: bobv Date: 2013-03-17 06:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e62e72c59cc Merge Changeset: 3be6a41ad358 Author: dholmes Date: 2013-03-18 19:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3be6a41ad358 8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: twisti, collins, bobv, jwilhelm ! make/jprt.properties Changeset: 804663118c1f Author: jprovino Date: 2013-03-22 10:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/804663118c1f Merge Changeset: aca25026e2a4 Author: vladidan Date: 2013-03-22 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aca25026e2a4 Merge From alejandro.murillo at oracle.com Sat Mar 23 13:19:01 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Mar 2013 20:19:01 +0000 Subject: hg: hsx/hsx25/hotspot: 52 new changesets Message-ID: <20130323202047.ADC914837B@hg.openjdk.java.net> Changeset: 4f7380dca47e Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: 7ae04e71af90 Author: amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 39432a1cefdd Author: minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author: coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author: zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author: zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author: dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author: sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author: sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/686916dc0439 8009457: SA: A small fix on "scanoops" command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java Changeset: 9960dce2024f Author: kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author: kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author: morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b4ce9870fd6 8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp Summary: add guarantee() to add_generation_memory_pool() Reviewed-by: kvn, twisti ! src/share/vm/services/memoryService.cpp Changeset: 0a2deac0bbfb Author: morris Date: 2013-03-16 07:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0a2deac0bbfb 8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp Summary: add guarantee() to oop_result inlines Reviewed-by: kvn, twisti ! src/cpu/x86/vm/frame_x86.inline.hpp Changeset: 9ef47379df20 Author: morris Date: 2013-03-16 07:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9ef47379df20 8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Summary: add null check to signal handler Reviewed-by: dcubed ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 8552f0992748 Author: kmo Date: 2013-03-15 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8552f0992748 8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers Reviewed-by: coleenp, roland Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java Changeset: 592f9722c72e Author: kmo Date: 2013-03-16 21:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/592f9722c72e Merge Changeset: 4efac99a998b Author: iignatyev Date: 2013-03-18 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4efac99a998b 8008211: Some of WB tests on compiler fail Reviewed-by: kvn, vlivanov ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: a5de0cc2f91c Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a5de0cc2f91c 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 578d9044c463 Author: roland Date: 2013-03-18 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/578d9044c463 Merge Changeset: be4d5c6c1f79 Author: neliasso Date: 2013-03-19 10:31 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/be4d5c6c1f79 8010121: Remove definition of ShouldNotReachHere2(msg) Reviewed-by: kvn, stefank, rbackman, twisti Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: f15df3af32c5 Author: morris Date: 2013-03-19 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f15df3af32c5 8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp Summary: add guarantee() to DoScheduling() Reviewed-by: twisti, kvn ! src/share/vm/opto/output.cpp Changeset: 75a28f465a12 Author: morris Date: 2013-03-19 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/75a28f465a12 8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: add NULL checks for compiler name Reviewed-by: twisti, kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 80208f353616 Author: kvn Date: 2013-03-19 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/80208f353616 8010222: 8007439 disabled inlining of cold accessor methods Summary: added missing parenthesis Reviewed-by: jrose ! src/share/vm/opto/bytecodeInfo.cpp Changeset: 2eef6d34833b Author: morris Date: 2013-03-19 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2eef6d34833b 8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp Summary: add guarantee() checks to merge_state_into_bb() Reviewed-by: kvn ! src/share/vm/oops/generateOopMap.cpp Changeset: 3b9368710f08 Author: morris Date: 2013-03-19 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3b9368710f08 8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp Summary: add guarantee() checks Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 1275835a4ccc Author: morris Date: 2013-03-19 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1275835a4ccc Merge Changeset: 41340544e182 Author: morris Date: 2013-03-20 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41340544e182 8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp Summary: add guarantee() to set_to_interpreted() Reviewed-by: kvn ! src/share/vm/code/compiledIC.cpp Changeset: 2dec1d9bfbe1 Author: morris Date: 2013-03-20 06:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2dec1d9bfbe1 8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp Summary: add guarantee() to get_instance_klass_for_declared_method_holder() Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp Changeset: 653d0346aa80 Author: morris Date: 2013-03-20 06:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/653d0346aa80 8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp Summary: add guarantee() to disqualify_method() Reviewed-by: kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: a59625d96f71 Author: morris Date: 2013-03-20 07:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a59625d96f71 8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp Summary: add guarantee() to insert_pre_post_loops() Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 98f3af397705 Author: twisti Date: 2013-03-20 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/98f3af397705 8006965: remove test_gamma and add dedicated test_* targets instead Reviewed-by: kvn, jcoomes ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make - make/test/Queens.java Changeset: 589aa23334ea Author: morris Date: 2013-03-21 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/589aa23334ea 8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp Summary: added guarantee() to pd_address_in_code() Reviewed-by: kvn ! src/cpu/x86/vm/relocInfo_x86.cpp Changeset: c3c64a973559 Author: morris Date: 2013-03-21 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c3c64a973559 8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp Summary: added guarantee() to print_entry_on() Reviewed-by: kvn ! src/share/vm/oops/constantPool.cpp Changeset: 3536ea6bc4df Author: morris Date: 2013-03-21 21:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3536ea6bc4df Merge - make/test/Queens.java Changeset: 79af1312fc2c Author: mgerdin Date: 2013-03-14 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79af1312fc2c 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap Reviewed-by: jmasa, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp Changeset: 3c226052f7dc Author: tschatzl Date: 2013-03-14 09:37 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c226052f7dc 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Summary: Use the correct collector to retrieve accumulated gen1 trace time Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp Changeset: 19f9fabd94cc Author: stefank Date: 2013-03-18 09:34 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19f9fabd94cc Merge ! src/share/vm/memory/metaspace.cpp Changeset: fa08949fe0cb Author: johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: e864cc14ca75 Author: johnc Date: 2013-03-19 00:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e864cc14ca75 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 1179172e9ec9 Author: johnc Date: 2013-03-19 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1179172e9ec9 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 7f0cb32dd233 Author: mgerdin Date: 2013-03-21 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7f0cb32dd233 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity" Reviewed-by: jmasa, johnc ! src/share/vm/memory/metaspace.cpp Changeset: 47902e9acb3a Author: stefank Date: 2013-03-22 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/47902e9acb3a Merge ! src/share/vm/memory/metaspace.cpp Changeset: 5855e849c7e6 Author: stefank Date: 2013-03-22 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5855e849c7e6 Merge Changeset: 499ccc15bbc8 Author: bpittore Date: 2013-03-15 15:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/499ccc15bbc8 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp Changeset: 9e62e72c59cc Author: bobv Date: 2013-03-17 06:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9e62e72c59cc Merge Changeset: 3be6a41ad358 Author: dholmes Date: 2013-03-18 19:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3be6a41ad358 8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: twisti, collins, bobv, jwilhelm ! make/jprt.properties Changeset: 804663118c1f Author: jprovino Date: 2013-03-22 10:09 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/804663118c1f Merge Changeset: aca25026e2a4 Author: vladidan Date: 2013-03-22 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aca25026e2a4 Merge Changeset: e3a41fc02348 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e3a41fc02348 Merge - make/test/Queens.java Changeset: 1c8db54ee9f3 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1c8db54ee9f3 Added tag hs25-b24 for changeset e3a41fc02348 ! .hgtags From alejandro.murillo at oracle.com Sat Mar 23 15:08:46 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Mar 2013 22:08:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130323220855.CF1D448380@hg.openjdk.java.net> Changeset: 4f7380dca47e Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: e3a41fc02348 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3a41fc02348 Merge - make/test/Queens.java Changeset: 1c8db54ee9f3 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1c8db54ee9f3 Added tag hs25-b24 for changeset e3a41fc02348 ! .hgtags Changeset: 59a41e1357ab Author: amurillo Date: 2013-03-23 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59a41e1357ab 8010498: new hotspot build - hs25-b25 Reviewed-by: jcoomes ! make/hotspot_version From john.coomes at oracle.com Mon Mar 25 06:17:44 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 25 Mar 2013 13:17:44 +0000 Subject: hg: hsx/hotspot-main: 22 new changesets Message-ID: <20130325131745.D7FFA483A7@hg.openjdk.java.net> Changeset: 52741ab7c601 Author: erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 235854886494 Author: katleman Date: 2013-03-11 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/235854886494 Merge Changeset: 145dbc56f931 Author: tbell Date: 2013-03-12 22:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/145dbc56f931 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Reviewed-by: katleman ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 0dc28db6525f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0dc28db6525f Added tag jdk8-b81 for changeset 145dbc56f931 ! .hgtags Changeset: ecc8fda8f187 Author: darcy Date: 2013-02-19 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ecc8fda8f187 8008435: Fix new build to include jdk.Supported in ct.sym Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: eca3bce3d151 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/eca3bce3d151 Merge Changeset: c641268c4532 Author: mduigou Date: 2013-02-20 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c641268c4532 8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com Reviewed-by: darcy ! make/scripts/webrev.ksh Changeset: b70196e01c53 Author: lana Date: 2013-02-21 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b70196e01c53 Merge Changeset: 5b0b6ef58dbf Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5b0b6ef58dbf 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! Makefile ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/sanity-rules.gmk ! make/scripts/hgforest.sh Changeset: e065107437b9 Author: alanb Date: 2013-02-26 14:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e065107437b9 8008978: nashorn-rules.gmk missing Reviewed-by: alanb Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com + make/nashorn-rules.gmk Changeset: cb0ac8979caa Author: tbell Date: 2013-02-26 09:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cb0ac8979caa 8009019: Updates to generated-configure.sh required for 8008914 Reviewed-by: sundar, jlaskey, jjg ! common/autoconf/generated-configure.sh Changeset: a9c8a32d09f9 Author: martin Date: 2013-03-05 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a9c8a32d09f9 8006988: build-infra: Configure fails if 'cl' is in path on linux Summary: Respect user CC and CXX environment variables; use cl iff on windows Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: c022bc48b7ed Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c022bc48b7ed Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: c4901c0e0579 Author: lana Date: 2013-03-05 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c4901c0e0579 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 929e2461818b Author: dholmes Date: 2013-03-05 22:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/929e2461818b 8009529: Fix for 8006988 missed closed configure changes Reviewed-by: mr ! common/autoconf/generated-configure.sh Changeset: b35d986ff276 Author: mduigou Date: 2013-03-06 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b35d986ff276 8009162: root repo "make test" target should run against image Reviewed-by: alanb, martin, erikj ! common/makefiles/Main.gmk Changeset: 980ccff2d4f5 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/980ccff2d4f5 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 22b9a31a92eb Author: lana Date: 2013-03-13 23:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/22b9a31a92eb Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: a69761ae281b Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a69761ae281b Merge Changeset: e2057191f6da Author: omajid Date: 2013-03-18 10:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e2057191f6da 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: 29153d0df68f Author: omajid Date: 2013-03-19 11:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/29153d0df68f 8010277: Configure doesn't fail when Xrender.h is missing Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 466685ba01bf Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/466685ba01bf Added tag jdk8-b82 for changeset 29153d0df68f ! .hgtags From daniel.daugherty at oracle.com Mon Mar 25 08:17:44 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 25 Mar 2013 09:17:44 -0600 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <514C67A9.1060106@oracle.com> References: <514C67A9.1060106@oracle.com> Message-ID: <51506A98.70103@oracle.com> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > Hi, > > Please review: > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.01/ make/bsd/makefiles/mapfile-vers-debug make/linux/makefiles/mapfile-vers-debug make/linux/makefiles/mapfile-vers-product make/solaris/makefiles/mapfile-vers It looks like the other entries are in alpha order so these two new entries should also be added in alpha order. src/share/vm/prims/jvm.cpp line 1510: return NULL; nit: indent should be two spaces line 1529: assert(false, "cannot find method"); line 1530: return NULL; // robustness Normally "robustness" comments flag logic after an assert() to indicate what we do in product mode to deal with the "bad" situation without crashing. In this case, we don't try to use 'm' after discovering that it is NULL so this could be simpler: Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); assert(m != NULL, "cannot find method"); return m; // caller has to deal with NULL in product mode Yes, I realize you only touched the comment here, but it served to point out the messiness of the existing code. line 1551: return NULL; line 1565: return NULL; line 1579: return NULL; nit: indent should be two spaces line 1632: return NULL; line 1613: return NULL; nit: indent should be two spaces src/share/vm/prims/jvm.h No comments. > > Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009382 > > In short, this is needed in order to implement the desired semantics > for reflecting over type annotations after a class redefine. This is > also needed in order to reduce the size overhead introduces on the JDK > side in the current type annotations reflection implementation. > > A prototype of the jdk changes can be found here: > http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ You should use a separate bug ID for the jdk repo changes. This will prevent confusion between when HSX with these changes is integrated into JDK8 and when the jdk repo changes are integrated into JDK8. Dan > > While in the neighborhood I also fixed a handful of unlikely but > possible null dereferences and removed an unused resource mark. I have > run jdk_lang on a fastdebug build to verify the removal of the > resource mark in addition to manual verification (also Dan helped me > look into this, but errors are mine). > > For Oracle reviewers, ccc is approved. > > testing done: > > jdk_lang with and without my prototype jdk changes x product/fastdebug > vm.quick.testlist > jprt standard build and test > > cheers > /Joel > > From jesper.wilhelmsson at oracle.com Mon Mar 25 09:29:20 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 17:29:20 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans Message-ID: <51507B60.6030809@oracle.com> Hi, Sorry for cross posting, but I think this could be useful for several areas. I would like to add Solaris Studio / NetBeans project files for the entire OpenJDK project. To clarify: One project that contains the entire OpenJDK. With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly fast and even though I personally mostly work in the HotSpot tree, I tend to always clone and build the entire JDK forest. I find this to have several benefits. Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ The configuration in this project is currently Mac only. Linux and Solaris configurations are also planned. The webrev is made from the jdk8/build repository which is where I think a change like this should go in. Let me know if you think something else. To use this project (once pushed): 1. Clone your favorite repository hg clone http://hg.openjdk.java.net/hsx/hotspot-gc 2. Get the whole forest cd hotspot-gc sh get_source.sh 3. Configure sh configure 4. Open Solaris studio / NetBeans and load the project. The project in located in the common directory. Thanks, /Jesper From dmitry.samersoff at oracle.com Mon Mar 25 10:11:33 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 21:11:33 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <51508545.6040102@oracle.com> Jesper, Tryed to apply your patch as I'm quite inetresting to have really working NB project for jdk and hotspot. 1. Directory structure looks strange (see screenshot1) 2. netbeans doesn't work for JDK tests (see screenshot2) - netbeans doesn't pick files from test directory (JDK-only project have the same issue) netbeans doesn't pick changes from files in JDK tree - i.e if I add/change class name in JDK tree, netbeans still treated it as unresolved within test (JDK-only project have the same issue) -Dmitry On 2013-03-25 20:29, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several > areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK > is fairly fast and even though I personally mostly work in the HotSpot > tree, I tend to always clone and build the entire JDK forest. I find > this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and > Solaris configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think > a change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Mon Mar 25 10:11:54 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 21:11:54 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <5150855A.9020909@oracle.com> Jesper, Tried to apply your patch as I'm quite interesting to have really working NB project for jdk and hotspot. 1. Directory structure looks strange (see screenshot1) 2. netbeans doesn't work for JDK tests (see screenshot2) - netbeans doesn't pick files from test directory (JDK-only project have the same issue) netbeans doesn't pick changes from files in JDK tree - i.e if I add/change class name in JDK tree, netbeans still treated it as unresolved within test (JDK-only project have the same issue) -Dmitry On 2013-03-25 20:29, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several > areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK > is fairly fast and even though I personally mostly work in the HotSpot > tree, I tend to always clone and build the entire JDK forest. I find > this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and > Solaris configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think > a change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From volker.simonis at gmail.com Mon Mar 25 10:15:11 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 18:15:11 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: Hi Jesper, first of all I highly welcome your initiative! Nevertheless I have some questions: - Who will support these project files? As far as I can see, they will have to be updated at least every time a file will be added, renamed or deleted. Experience shows that such kind of project files tend to get outdated very fast. Do you have any ideas how this problem can be addressed? - Where will other platform configurations go to? Will they be all stored in "configurations.xml" - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, CC_INTERP, etc..)? Will they all have to go into the same "configurations.xml" It seems that the "configurations.xml" might get quite big and complex with all these configurations. Thank you and best regards, Volker On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several areas. > > I would like to add Solaris Studio / NetBeans project files for the entire > OpenJDK project. To clarify: One project that contains the entire OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK is > fairly fast and even though I personally mostly work in the HotSpot tree, I > tend to always clone and build the entire JDK forest. I find this to have > several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Mon Mar 25 11:03:31 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 19:03:31 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: References: <51507B60.6030809@oracle.com> Message-ID: <51509173.6020803@oracle.com> Volker Simonis skrev 25/3/13 6:15 PM: > Hi Jesper, > > first of all I highly welcome your initiative! This is a joint initiative with Vladimir Voskresensky who works in the Solaris Studio team. > > Nevertheless I have some questions: > > - Who will support these project files? As far as I can see, they will > have to be updated at least every time a file will be added, renamed > or deleted. Experience shows that such kind of project files tend to > get outdated very fast. Do you have any ideas how this problem can be > addressed? One thing that was a pleasant surprise to me when I created the nbproject was that if I add new source files, they are automatically brought into the project. And when running make, the code assistant will be updated with the new definitions in the new files. So even if the project file is slightly out of date it will auto-update itself once you run make the first time. I don't think I should volunteer to keep the project files up to date, but since I will be using Solaris Studio for my daily work, and since I will be notified about changes in the project files every time I run "hg status", it seems pretty likely that I will push an updated project once in a while. - At least for Mac. > - Where will other platform configurations go to? Will they be all > stored in "configurations.xml" Yes, I think so. > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, > CC_INTERP, etc..)? Will they all have to go into the same > "configurations.xml" If I'm not mistaken these are different make targets, right? I don't think you need to have separate configurations saved in the project files for different make targets. Vladimir can answer this much better, but the way I have done it previously has simply been to edit the make command if I wanted to build a different target, and the code assistant is automatically updated when running make ("make clean" may be needed in some cases). > > It seems that the "configurations.xml" might get quite big and complex > with all these configurations. It's not too big right now IMHO. If it starts to grow unexpectedly in the future I agree that we should reconsider the choice to store it in the repository. Thank you for your comments, /Jesper > > Thank you and best regards, > Volker > > On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson > wrote: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several areas. >> >> I would like to add Solaris Studio / NetBeans project files for the entire >> OpenJDK project. To clarify: One project that contains the entire OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK is >> fairly fast and even though I personally mostly work in the HotSpot tree, I >> tend to always clone and build the entire JDK forest. I find this to have >> several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and Solaris >> configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I think a >> change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper From jesper.wilhelmsson at oracle.com Mon Mar 25 11:35:02 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 19:35:02 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51508545.6040102@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> Message-ID: <515098D6.4080404@oracle.com> Dmitry Samersoff skrev 25/3/13 6:11 PM: > Jesper, > > Tryed to apply your patch as I'm quite inetresting to have really > working NB project for jdk and hotspot. > > 1. Directory structure looks strange (see screenshot1) The structure in the Projects tab shows the NetBeans project hierarchy. It's not related to the OpenJDK project hierarchy. The "Files" tab (to the right of the project tab) will show you the directory structure as it looks on disk. I think this is the tab you want to use for browsing the directories. > 2. netbeans doesn't work for JDK tests (see screenshot2) - > > netbeans doesn't pick files > from test directory (JDK-only project have the same issue) > > netbeans doesn't pick changes from files in JDK tree - i.e > if I add/change class name in JDK tree, netbeans still treated it > as unresolved within test (JDK-only project have the same issue) I have mainly looked at the hotspot code when creating the project so I'm not surprised to see that there are things that don't work in for instance the jdk. I'll look at this tomorrow. Thank you for your comments, /Jesper > > -Dmitry > > > > On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several >> areas. >> >> I would like to add Solaris Studio / NetBeans project files for the >> entire OpenJDK project. To clarify: One project that contains the entire >> OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK >> is fairly fast and even though I personally mostly work in the HotSpot >> tree, I tend to always clone and build the entire JDK forest. I find >> this to have several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and >> Solaris configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I think >> a change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper > > From jesper.wilhelmsson at oracle.com Mon Mar 25 11:46:53 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 25 Mar 2013 18:46:53 +0000 Subject: hg: hsx/hsx24/hotspot: 8009992: Prepare tracing of promotion failed for integration of evacuation failed Message-ID: <20130325184657.799FE483B1@hg.openjdk.java.net> Changeset: 5967e5c9c7f0 Author: jwilhelm Date: 2013-03-25 15:19 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5967e5c9c7f0 8009992: Prepare tracing of promotion failed for integration of evacuation failed Summary: Refactorisation to introduce CopyFaiedInfo that is used by PromotionFailedInfo and will be used by EvacuationFailedInfo as well Reviewed-by: ehelin, johnc, brutisso ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp + src/share/vm/gc_implementation/shared/copyFailedInfo.hpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp - src/share/vm/gc_implementation/shared/promotionFailedInfo.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/trace/trace.xml From dmitry.samersoff at oracle.com Mon Mar 25 11:56:17 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 22:56:17 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <515098D6.4080404@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> <515098D6.4080404@oracle.com> Message-ID: <51509DD1.3020308@oracle.com> Jesper, On 2013-03-25 22:35, Jesper Wilhelmsson wrote: > Dmitry Samersoff skrev 25/3/13 6:11 PM: >> Jesper, >> >> Tryed to apply your patch as I'm quite inetresting to have really >> working NB project for jdk and hotspot. >> >> 1. Directory structure looks strange (see screenshot1) > > The structure in the Projects tab shows the NetBeans project hierarchy. > It's not related to the OpenJDK project hierarchy. The "Files" tab (to > the right of the project tab) will show you the directory structure as > it looks on disk. I think this is the tab you want to use for browsing > the directories. I'm using Linux and fresh netbeans copy, so fd and macosx_* projects comes from your patch for sure. Please take a look at it. -Dmitry > >> 2. netbeans doesn't work for JDK tests (see screenshot2) - >> >> netbeans doesn't pick files >> from test directory (JDK-only project have the same issue) >> >> netbeans doesn't pick changes from files in JDK tree - i.e >> if I add/change class name in JDK tree, netbeans still treated it >> as unresolved within test (JDK-only project have the same issue) > > I have mainly looked at the hotspot code when creating the project so > I'm not surprised to see that there are things that don't work in for > instance the jdk. I'll look at this tomorrow. > > Thank you for your comments, > /Jesper > >> >> -Dmitry >> >> >> >> On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several >>> areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the >>> entire OpenJDK project. To clarify: One project that contains the entire >>> OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK >>> is fairly fast and even though I personally mostly work in the HotSpot >>> tree, I tend to always clone and build the entire JDK forest. I find >>> this to have several benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and >>> Solaris configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I think >>> a change like this should go in. Let me know if you think something >>> else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From jesper.wilhelmsson at oracle.com Mon Mar 25 12:30:32 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 20:30:32 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51509DD1.3020308@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> <515098D6.4080404@oracle.com> <51509DD1.3020308@oracle.com> Message-ID: <5150A5D8.1000800@oracle.com> Dmitry, Dmitry Samersoff skrev 25/3/13 7:56 PM: > Jesper, > > On 2013-03-25 22:35, Jesper Wilhelmsson wrote: >> Dmitry Samersoff skrev 25/3/13 6:11 PM: >>> Jesper, >>> >>> Tryed to apply your patch as I'm quite inetresting to have really >>> working NB project for jdk and hotspot. >>> >>> 1. Directory structure looks strange (see screenshot1) >> >> The structure in the Projects tab shows the NetBeans project hierarchy. >> It's not related to the OpenJDK project hierarchy. The "Files" tab (to >> the right of the project tab) will show you the directory structure as >> it looks on disk. I think this is the tab you want to use for browsing >> the directories. > > I'm using Linux and fresh netbeans copy, so fd and macosx_* projects > comes from your patch for sure. > > Please take a look at it. Sorry, I misinterpreted your initial comment. Yes, that is a bug. I have found the cause and will fix it. Thanks, /Jesper > > -Dmitry > >> >>> 2. netbeans doesn't work for JDK tests (see screenshot2) - >>> >>> netbeans doesn't pick files >>> from test directory (JDK-only project have the same issue) >>> >>> netbeans doesn't pick changes from files in JDK tree - i.e >>> if I add/change class name in JDK tree, netbeans still treated it >>> as unresolved within test (JDK-only project have the same issue) >> >> I have mainly looked at the hotspot code when creating the project so >> I'm not surprised to see that there are things that don't work in for >> instance the jdk. I'll look at this tomorrow. >> >> Thank you for your comments, >> /Jesper >> >>> >>> -Dmitry >>> >>> >>> >>> On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Sorry for cross posting, but I think this could be useful for several >>>> areas. >>>> >>>> I would like to add Solaris Studio / NetBeans project files for the >>>> entire OpenJDK project. To clarify: One project that contains the entire >>>> OpenJDK. >>>> >>>> >>>> With the new build infrastructure in JDK 8 building the entire OpenJDK >>>> is fairly fast and even though I personally mostly work in the HotSpot >>>> tree, I tend to always clone and build the entire JDK forest. I find >>>> this to have several benefits. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>>> >>>> The configuration in this project is currently Mac only. Linux and >>>> Solaris configurations are also planned. >>>> >>>> The webrev is made from the jdk8/build repository which is where I think >>>> a change like this should go in. Let me know if you think something >>>> else. >>>> >>>> >>>> >>>> To use this project (once pushed): >>>> >>>> 1. Clone your favorite repository >>>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>>> >>>> 2. Get the whole forest >>>> cd hotspot-gc >>>> sh get_source.sh >>>> >>>> 3. Configure >>>> sh configure >>>> >>>> 4. Open Solaris studio / NetBeans and load the project. >>>> The project in located in the common directory. >>>> >>>> >>>> Thanks, >>>> /Jesper >>> >>> > > From volker.simonis at gmail.com Mon Mar 25 12:46:12 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 20:46:12 +0100 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50FD1529.7010303@oracle.com> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: Hi, I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again. These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24. Can somebody please open a bug for this issue and review the changes. (I can also submit a full RFR with webrev once there's a bug ID). Thank you and best regards, Volker On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo < alejandro.murillo at oracle.com> wrote: > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we take a > snapshot of hs24 > cheers > Alejandro > > > On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: >> >>> Hi Alejandro, >>> >>> Have updated the webrev (just off by one line in 1 file) and built both >>> normal >>> hotspot and zero on x86_64 based on the hsx24 repo head: >>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/hsx24b31-** >>> 8000780-zero_20130118_webrev/ >>> [Also now contains updated copyrights] >>> >>> Cheers! >>> Chris >>> >>> On 18/01/13 05:56 AM, Alejandro E Murillo wrote: >>> >>>> >>>> Hi Chris (Phillips) >>>> I just got a snapshot of hs24 and bumped the build number to b31, >>>> so we can resume pushing bug fixes to it. >>>> Unfortunately the patch in the webrev at [1] does not apply cleanly >>>> anymore, >>>> Can you guys reapply the changes to clean clone of [2] and send the >>>> new webrev? >>>> Then if the previous reviewers approve it, I will push that soon >>>> after so it makes >>>> it into next week snapshot. Apologies for the extra work >>>> >>>> [1]http://integral-portal.**lgonqn.org/temp/ChrisPhi/** >>>> jdk7u-dev-zero-hs24b29_**20121222/ >>>> >>>> [2] http://hg.openjdk.java.net/**hsx/hsx24/hotspot >>>> >>>> >>>> >>>> Thanks >>>> Alejandro >>>> >>>> >>>> On 1/2/2013 1:02 PM, Christian Thalinger wrote: >>>> >>>>> On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T >>>>> O wrote: >>>>> >>>>> Hi Alejandro, >>>>>> Oops emails crossed in the net ... >>>>>> See my latest email , I had to regenerate the webrev and patch - >>>>>> This webrev s/b ok: >>>>>> >>>>>> Webrev: >>>>>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/jdk7u-dev-** >>>>>> zero-hs24b29_20121222/ >>>>>> >>>>>> That looks good. -- Chris >>>>> >>>>> Chris >>>>>> >>>>>> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>>>>> >>>>>>> Hi Chris, >>>>>>> In that case is not necessary. >>>>>>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>>>>>> but looks like it is against hsx/hsx24/hotspot. >>>>>>> BTW, I went to check the webrev link and is unreachable, can you >>>>>>> check >>>>>>> that? >>>>>>> Thanks >>>>>>> Alejandro >>>>>>> >>>>>>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>>>>> >>>>>>>> Hi Alejandro, >>>>>>>> >>>>>>>> The only change since I tested this afternoon is the change >>>>>>>> for the hotspot_version. I will re-run tests if you wish but it >>>>>>>> seems >>>>>>>> unnecessary. >>>>>>>> >>>>>>>> Cheers! >>>>>>>> Chris >>>>>>>> >>>>>>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>>>>> >>>>>>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>>>>>> sponsor >>>>>>>>>> - Twisti ? } >>>>>>>>>> >>>>>>>>>> Attached is a backport (essentially resurrection of the Permgen >>>>>>>>>> code) >>>>>>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and >>>>>>>>>> built >>>>>>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>>>>>> >>>>>>>>>> Please review. >>>>>>>>>> >>>>>>>>>> Cheers! >>>>>>>>>> Chris >>>>>>>>>> PS >>>>>>>>>> Webrev is here: >>>>>>>>>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/jdk7u-dev-** >>>>>>>>>> zero/hs24b28/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>>>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>>>>>> Can you rework the patch/webrev against this repo: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/**hsx/hsx24/hotspot >>>>>>>>> >>>>>>>>> once it's reviewed I can push it >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>> >>>> > -------------- next part -------------- diff --git a/src/share/vm/interpreter/bytecodeInterpreter.cpp b/src/share/vm/interpreter/bytecodeInterpreter.cpp --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp @@ -2173,12 +2173,13 @@ // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. ConstantPoolCacheEntry* cache = cp->entry_at(index); - oop result = cache->f1_as_instance(); - if (result == NULL) { + if (cache->f1_as_instance() == NULL) { CALL_VM(InterpreterRuntime::resolve_ldc(THREAD, (Bytecodes::Code) opcode), handle_exception); - result = cache->f1_as_instance(); + // GC might move cache while returning from VM call. + cache = cp->entry_at(index); // reload } + oop result = cache->f1_as_instance(); VERIFY_OOP(result); SET_STACK_OBJECT(result, 0); @@ -2197,23 +2198,19 @@ u4 index = Bytes::get_native_u4(pc+1); ConstantPoolCacheEntry* cache = cp->secondary_entry_at(index); - oop result = cache->f1_as_instance(); // We are resolved if the f1 field contains a non-null object (CallSite, etc.) // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. assert(constantPoolCacheOopDesc::is_secondary_index(index), "incorrect format"); - if (! cache->is_resolved((Bytecodes::Code) opcode)) { + if (cache->is_f1_null()) { CALL_VM(InterpreterRuntime::resolve_invokedynamic(THREAD), handle_exception); - result = cache->f1_as_instance(); + // GC might move cache while returning from VM call. + cache = cp->secondary_entry_at(index); // reload } - VERIFY_OOP(result); - oop method_handle = java_lang_invoke_CallSite::target(result); - CHECK_NULL(method_handle); - - methodOop method = cache->f1_as_method(); + methodOop method = cache->f2_as_vfinal_method(); VERIFY_OOP(method); if (cache->has_appendix()) { @@ -2241,10 +2238,11 @@ if (! cache->is_resolved((Bytecodes::Code) opcode)) { CALL_VM(InterpreterRuntime::resolve_invokehandle(THREAD), handle_exception); - cache = cp->entry_at(index); + // GC might move cache while returning from VM call. + cache = cp->entry_at(index); // reload } - methodOop method = cache->f1_as_method(); + methodOop method = cache->f2_as_vfinal_method(); VERIFY_OOP(method); From volker.simonis at gmail.com Mon Mar 25 12:59:18 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 20:59:18 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51509173.6020803@oracle.com> References: <51507B60.6030809@oracle.com> <51509173.6020803@oracle.com> Message-ID: On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Volker Simonis skrev 25/3/13 6:15 PM: > > Hi Jesper, >> >> first of all I highly welcome your initiative! >> > > This is a joint initiative with Vladimir Voskresensky who works in the > Solaris Studio team. > > > >> Nevertheless I have some questions: >> >> - Who will support these project files? As far as I can see, they will >> have to be updated at least every time a file will be added, renamed >> or deleted. Experience shows that such kind of project files tend to >> get outdated very fast. Do you have any ideas how this problem can be >> addressed? >> > > One thing that was a pleasant surprise to me when I created the nbproject > was that if I add new source files, they are automatically brought into the > project. And when running make, the code assistant will be updated with the > new definitions in the new files. So even if the project file is slightly > out of date it will auto-update itself once you run make the first time. > > I don't think I should volunteer to keep the project files up to date, but > since I will be using Solaris Studio for my daily work, and since I will be > notified about changes in the project files every time I run "hg status", > it seems pretty likely that I will push an updated project once in a while. > - At least for Mac. > > > - Where will other platform configurations go to? Will they be all >> stored in "configurations.xml" >> > > Yes, I think so. > > > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, >> CC_INTERP, etc..)? Will they all have to go into the same >> "configurations.xml" >> > > If I'm not mistaken these are different make targets, right? I don't think > you need to have separate configurations saved in the project files for > different make targets. Vladimir can answer this much better, but the way I > have done it previously has simply been to edit the make command if I > wanted to build a different target, and the code assistant is automatically > updated when running make ("make clean" may be needed in some cases). > > These are partially make targets but also preprocessor defines set by various make targets. For example you may have different class definitions depending on whether "DEBUG" is defined or not. Actually I don't understand how code assistants is automatically updated if I do a "make clean" with a different make target if I haven't defined the new preprocessor defines for the project. Is this by parsing the generated libjvm.so? That's a neat feature of NetBeans but as far as I know it only works if the VM is compiled with '-g3' which HotSpot isn't by default. > > >> It seems that the "configurations.xml" might get quite big and complex >> with all these configurations. >> > > It's not too big right now IMHO. If it starts to grow unexpectedly in the > future I agree that we should reconsider the choice to store it in the > repository. > > Thank you for your comments, > /Jesper > > > >> Thank you and best regards, >> Volker >> >> On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson >> wrote: >> >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several >>> areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the >>> entire >>> OpenJDK project. To clarify: One project that contains the entire >>> OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK is >>> fairly fast and even though I personally mostly work in the HotSpot >>> tree, I >>> tend to always clone and build the entire JDK forest. I find this to have >>> several benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~**jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and >>> Solaris >>> configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I think >>> a >>> change like this should go in. Let me know if you think something else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/**hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper >>> >> From jesper.wilhelmsson at oracle.com Mon Mar 25 13:11:28 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 21:11:28 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: References: <51507B60.6030809@oracle.com> <51509173.6020803@oracle.com> Message-ID: <5150AF70.8080508@oracle.com> Volker Simonis skrev 25/3/13 8:59 PM: > > > On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson > > wrote: > > Volker Simonis skrev 25/3/13 6:15 PM: > > Hi Jesper, > > first of all I highly welcome your initiative! > > > This is a joint initiative with Vladimir Voskresensky who works in the > Solaris Studio team. > > > > Nevertheless I have some questions: > > - Who will support these project files? As far as I can see, they will > have to be updated at least every time a file will be added, renamed > or deleted. Experience shows that such kind of project files tend to > get outdated very fast. Do you have any ideas how this problem can be > addressed? > > > One thing that was a pleasant surprise to me when I created the nbproject > was that if I add new source files, they are automatically brought into the > project. And when running make, the code assistant will be updated with the > new definitions in the new files. So even if the project file is slightly > out of date it will auto-update itself once you run make the first time. > > I don't think I should volunteer to keep the project files up to date, but > since I will be using Solaris Studio for my daily work, and since I will be > notified about changes in the project files every time I run "hg status", it > seems pretty likely that I will push an updated project once in a while. > - At least for Mac. > > > - Where will other platform configurations go to? Will they be all > stored in "configurations.xml" > > > Yes, I think so. > > > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, > CC_INTERP, etc..)? Will they all have to go into the same > "configurations.xml" > > > If I'm not mistaken these are different make targets, right? I don't think > you need to have separate configurations saved in the project files for > different make targets. Vladimir can answer this much better, but the way I > have done it previously has simply been to edit the make command if I wanted > to build a different target, and the code assistant is automatically updated > when running make ("make clean" may be needed in some cases). > > > These are partially make targets but also preprocessor defines set by various > make targets. For example you may have different class definitions depending on > whether "DEBUG" is defined or not. Actually I don't understand how code > assistants is automatically updated if I do a "make clean" with a different make > target if I haven't defined the new preprocessor defines for the project. Is > this by parsing the generated libjvm.so? That's a neat feature of NetBeans but > as far as I know it only works if the VM is compiled with '-g3' which HotSpot > isn't by default. In the current project all info about how the files are compiled are taken from the make logs. /Jesper > > > > It seems that the "configurations.xml" might get quite big and complex > with all these configurations. > > > It's not too big right now IMHO. If it starts to grow unexpectedly in the > future I agree that we should reconsider the choice to store it in the > repository. > > Thank you for your comments, > /Jesper > > > > Thank you and best regards, > Volker > > On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson > __> > wrote: > > Hi, > > Sorry for cross posting, but I think this could be useful for > several areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire > OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire > OpenJDK is > fairly fast and even though I personally mostly work in the HotSpot > tree, I > tend to always clone and build the entire JDK forest. I find this to > have > several benefits. > > Webrev: http://cr.openjdk.java.net/~__jwilhelm/7074926/webrev/ > > > The configuration in this project is currently Mac only. Linux and > Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I > think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/__hsx/hotspot-gc > > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper > > From christian.thalinger at oracle.com Mon Mar 25 14:37:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Mar 2013 14:37:02 -0700 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: <770D966D-A11C-4777-BC55-78DEE4B00A21@oracle.com> On Mar 25, 2013, at 12:46 PM, Volker Simonis wrote: > Hi, > > I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again. > > These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24. > > Can somebody please open a bug for this issue and review the changes. (I can also submit a full RFR with webrev once there's a bug ID). 8010770: Zero: back port of 8000780 to HS24 broke JSR 292 -- Chris > > Thank you and best regards, > Volker > > > On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo wrote: > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we take a snapshot of hs24 > cheers > Alejandro > > > On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: > Hi Alejandro, > > Have updated the webrev (just off by one line in 1 file) and built both > normal > hotspot and zero on x86_64 based on the hsx24 repo head: > http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ > [Also now contains updated copyrights] > > Cheers! > Chris > > On 18/01/13 05:56 AM, Alejandro E Murillo wrote: > > Hi Chris (Phillips) > I just got a snapshot of hs24 and bumped the build number to b31, > so we can resume pushing bug fixes to it. > Unfortunately the patch in the webrev at [1] does not apply cleanly > anymore, > Can you guys reapply the changes to clean clone of [2] and send the > new webrev? > Then if the previous reviewers approve it, I will push that soon > after so it makes > it into next week snapshot. Apologies for the extra work > > [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot > > > > Thanks > Alejandro > > > On 1/2/2013 1:02 PM, Christian Thalinger wrote: > On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T > O wrote: > > Hi Alejandro, > Oops emails crossed in the net ... > See my latest email , I had to regenerate the webrev and patch - > This webrev s/b ok: > > Webrev: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > That looks good. -- Chris > > Chris > > On 22/12/12 01:03 PM, Alejandro E Murillo wrote: > Hi Chris, > In that case is not necessary. > I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot > but looks like it is against hsx/hsx24/hotspot. > BTW, I went to check the webrev link and is unreachable, can you check > that? > Thanks > Alejandro > > On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: > Hi Alejandro, > > The only change since I tested this afternoon is the change > for the hotspot_version. I will re-run tests if you wish but it seems > unnecessary. > > Cheers! > Chris > > On 21/12/12 07:40 PM, Alejandro E Murillo wrote: > On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: > Hi > > {Not sure if this needs a new bug or not, it definitely needs a > sponsor > - Twisti ? } > > Attached is a backport (essentially resurrection of the Permgen > code) > of 8000780 now updated with Roman Kennke's comments. Checked and > built > against hsx24b28. (Current jdk7u-dev hs) > > Please review. > > Cheers! > Chris > PS > Webrev is here: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ > > > Hi > jdk7u-dev/hotspot corresponds to hs24-b27. > I just got the hs24 snapshot for b28 and bumped the number to b29, > Can you rework the patch/webrev against this repo: > > http://hg.openjdk.java.net/hsx/hsx24/hotspot > > once it's reviewed I can push it > > Thanks > > > > > > > > From serguei.spitsyn at oracle.com Tue Mar 26 01:37:16 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Mar 2013 01:37:16 -0700 Subject: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition In-Reply-To: <513E8B88.6070904@oracle.com> References: <513E8B88.6070904@oracle.com> Message-ID: <51515E3C.7040307@oracle.com> Please, review the following fix. The fix was preliminarily reviewed by Coleen, Christian and John but still a final and open jdk review is needed. So that, everyone is welcome to review the fix! This is open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ The CR is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 https://jbs.oracle.com/bugs/browse/JDK-8008511 The problem is that the old version of the bootstrap method is re-invoked after a popframe from the bootstrap method execution. It is because the MemberName keeps a stale reference to the old method version. The solution (suggested by John Rose) is to lazily create and keep up-to-date a MemberNameTable which plays a role of MemberName cache assosiated with the InstanceKlass. Then, at the Class redefinition, this cache is used to replace the old method references in the MemberName's with the new method references. The MemberNameTable is based on the GrowableArray. A C_HEAP array is allocated at the first call to InstanceKlass::add_member_name(). It is released in the InstanceKlass::release_C_heap_structures(). A global week reference to member name oop is stored in the MemberNameTable. It allowed to avoid having the oops_do() in the MemberNameTable. Also, the MemberNameTable won't hold member name oops in memory. The MemberNameTable_lock mutex is added to serialize MemberNameTable's updates. The following No_Safepoint_Verifier has been disabled: * src/share/vm/prims/methodHandles.cpp*: 799 int MethodHandles::find_MemberNames(Klass* k, . . . 803 DEBUG_ONLY(No_Safepoint_Verifier nsv); It is probably Ok, but, please, let me know if it is not. The assert related to locking is fired if it is not disabled. Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. Thanks, Serguei From david.holmes at oracle.com Tue Mar 26 02:17:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 19:17:33 +1000 Subject: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition In-Reply-To: <51515E3C.7040307@oracle.com> References: <513E8B88.6070904@oracle.com> <51515E3C.7040307@oracle.com> Message-ID: <515167AD.5040606@oracle.com> Hi Serguei, The removal of the NoSafepointVerifier could be problematic. If that method is never meant to be on the stack when you block for a safepoint then the method is atomic with respect to the safepoint - and so can not suffer interference from actions that occur at a safepoint (like class unloading (?) ). Now I presume that somewhere from that method you end up taking the mutex and so can block at a safepoint (or block on the lock and so still allow a safepoint to occur) - which might invalidate assumptions the method has about "safepoint atomicity". You need to understand why the NSV was put there in the first place. David ------ On 26/03/2013 6:37 PM, serguei.spitsyn at oracle.com wrote: > > Please, review the following fix. > The fix was preliminarily reviewed by Coleen, Christian > and John but still a final and open jdk review is needed. > So that, everyone is welcome to review the fix! > > This is open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ > > The CR is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 > https://jbs.oracle.com/bugs/browse/JDK-8008511 > > > The problem is that the old version of the bootstrap method is re-invoked > after a popframe from the bootstrap method execution. > It is because the MemberName keeps a stale reference to the old method > version. > > The solution (suggested by John Rose) is to lazily create and keep > up-to-date a MemberNameTable > which plays a role of MemberName cache assosiated with the InstanceKlass. > Then, at the Class redefinition, this cache is used to replace the old > method > references in the MemberName's with the new method references. > > The MemberNameTable is based on the GrowableArray. > A C_HEAP array is allocated at the first call to > InstanceKlass::add_member_name(). > It is released in the InstanceKlass::release_C_heap_structures(). > > A global week reference to member name oop is stored in the MemberNameTable. > It allowed to avoid having the oops_do() in the MemberNameTable. > Also, the MemberNameTable won't hold member name oops in memory. > > The MemberNameTable_lock mutex is added to serialize MemberNameTable's > updates. > > The following No_Safepoint_Verifier has been disabled: > * src/share/vm/prims/methodHandles.cpp*: > > 799 int MethodHandles::find_MemberNames(Klass* k, > . . . > 803 DEBUG_ONLY(No_Safepoint_Verifier nsv); > > It is probably Ok, but, please, let me know if it is not. > The assert related to locking is fired if it is not disabled. > > Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms > (32 vs 64-bit too). > The testing looks good so far. > > > Thanks, > Serguei > > From joel.franck at oracle.com Tue Mar 26 03:32:59 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 26 Mar 2013 11:32:59 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <51506A98.70103@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> Message-ID: <5151795B.7080109@oracle.com> Hi, Also including build-dev since this touches some makefiles. Thanks Dan! see inline, also new webrev: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: > On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > make/bsd/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-product > make/solaris/makefiles/mapfile-vers > It looks like the other entries are in alpha order so these > two new entries should also be added in alpha order. > Fixed. I also noticed I forgot to update one of the bsd makefiles. > src/share/vm/prims/jvm.cpp > line 1510: return NULL; > nit: indent should be two spaces > > line 1529: assert(false, "cannot find method"); > line 1530: return NULL; // robustness > Normally "robustness" comments flag logic after an assert() > to indicate what we do in product mode to deal with the "bad" > situation without crashing. In this case, we don't try to use > 'm' after discovering that it is NULL so this could be simpler: > > Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); > assert(m != NULL, "cannot find method"); > return m; // caller has to deal with NULL in product mode > > Yes, I realize you only touched the comment here, but it > served to point out the messiness of the existing code. > Good suggestion. Fixed. > line 1551: return NULL; > line 1565: return NULL; > line 1579: return NULL; > nit: indent should be two spaces > > line 1632: return NULL; > line 1613: return NULL; > nit: indent should be two spaces Fixed all indent nits. >> >> A prototype of the jdk changes can be found here: >> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ > > You should use a separate bug ID for the jdk repo changes. This will > prevent confusion between when HSX with these changes is integrated > into JDK8 and when the jdk repo changes are integrated into JDK8. > The JDK changes have a separate bug, sorry if this was unclear. The jdk changes shown are just a proof of concept, intended to highlight that my HotSpot changes have actually been run. I will send out a separate review request in the future for the JDK changes. cheers /Joel From ChrisPhi at LGonQn.Org Tue Mar 26 05:29:04 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Tue, 26 Mar 2013 08:29:04 -0400 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: <51519490.6070003@LGonQn.Org> Hi Volker Thanks! Good catch.. after applying this , I've gotten further in jsr292 for arm 32. Chris On 25/03/13 03:46 PM, Volker Simonis wrote: > Hi, > > I've just realized that something must have gone wrong during the > downport of 8000780 to hsx24 (probably because of the change of the > content of the f1 and f2 fields in the ConstantPoolCacheEntry between > hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as > '_invokehandle' don't work in the CC-interpreter anymore. The attached > patch (against hsx24) fixes the problem and lets the Zero-VM pass the > java/lang/invoke JTreg tests again. > > These changes are needed for making JSR292 work in the Zero-port in > jdk7u with hsx24. > > Can somebody please open a bug for this issue and review the changes. > (I can also submit a full RFR with webrev once there's a bug ID). > > Thank you and best regards, > Volker > > > On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo > > > wrote: > > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we > take a snapshot of hs24 > cheers > Alejandro > > > On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > > Looks good. > > Vladimir > > On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: > > Hi Alejandro, > > Have updated the webrev (just off by one line in 1 file) > and built both > normal > hotspot and zero on x86_64 based on the hsx24 repo head: > http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ > [Also now contains updated copyrights] > > Cheers! > Chris > > On 18/01/13 05:56 AM, Alejandro E Murillo wrote: > > > Hi Chris (Phillips) > I just got a snapshot of hs24 and bumped the build > number to b31, > so we can resume pushing bug fixes to it. > Unfortunately the patch in the webrev at [1] does not > apply cleanly > anymore, > Can you guys reapply the changes to clean clone of [2] > and send the > new webrev? > Then if the previous reviewers approve it, I will > push that soon > after so it makes > it into next week snapshot. Apologies for the extra work > > [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > > [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot > > > > Thanks > Alejandro > > > On 1/2/2013 1:02 PM, Christian Thalinger wrote: > > On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T > O > wrote: > > Hi Alejandro, > Oops emails crossed in the net ... > See my latest email , I had to regenerate the > webrev and patch - > This webrev s/b ok: > > Webrev: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > > That looks good. -- Chris > > Chris > > On 22/12/12 01:03 PM, Alejandro E Murillo wrote: > > Hi Chris, > In that case is not necessary. > I initially thought the webrev was against > jdk7u/jdk7u-dev/hotspot > but looks like it is against > hsx/hsx24/hotspot. > BTW, I went to check the webrev link and > is unreachable, can you check > that? > Thanks > Alejandro > > On 12/21/2012 9:53 PM, Chris Phillips @ T > O wrote: > > Hi Alejandro, > > The only change since I tested this > afternoon is the change > for the hotspot_version. I will re-run > tests if you wish but it seems > unnecessary. > > Cheers! > Chris > > On 21/12/12 07:40 PM, Alejandro E > Murillo wrote: > > On 12/21/2012 4:34 PM, Chris > Phillips @ T O wrote: > > Hi > > {Not sure if this needs a new > bug or not, it definitely needs a > sponsor > - Twisti ? } > > Attached is a backport > (essentially resurrection of > the Permgen > code) > of 8000780 now updated with > Roman Kennke's comments. > Checked and > built > against hsx24b28. (Current > jdk7u-dev hs) > > Please review. > > Cheers! > Chris > PS > Webrev is here: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ > > > > Hi > jdk7u-dev/hotspot corresponds to > hs24-b27. > I just got the hs24 snapshot for > b28 and bumped the number to b29, > Can you rework the patch/webrev > against this repo: > > http://hg.openjdk.java.net/hsx/hsx24/hotspot > > once it's reviewed I can push it > > Thanks > > > > > > > From daniel.daugherty at oracle.com Tue Mar 26 06:05:43 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Mar 2013 07:05:43 -0600 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <51519D27.2090900@oracle.com> Thumbs up on the re-review. Dan On 3/26/13 4:32 AM, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = >> InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The > jdk changes shown are just a proof of concept, intended to highlight > that my HotSpot changes have actually been run. I will send out a > separate review request in the future for the JDK changes. > > cheers > /Joel From rickard.backman at oracle.com Tue Mar 26 06:33:20 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 26 Mar 2013 14:33:20 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <4A335290-E3B1-4F03-8A02-AB0C097D39F7@oracle.com> Joel, the change looks good. /R On Mar 26, 2013, at 11:32 AM, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The jdk changes shown are just a proof of concept, intended to highlight that my HotSpot changes have actually been run. I will send out a separate review request in the future for the JDK changes. > > cheers > /Joel From rickard.backman at oracle.com Tue Mar 26 07:40:16 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 26 Mar 2013 15:40:16 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <51506A98.70103@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> Message-ID: I'll sponsor the change. /R On Mar 25, 2013, at 4:17 PM, Daniel D. Daugherty wrote: > On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: >> Hi, >> >> Please review: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.01/ > > make/bsd/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-product > make/solaris/makefiles/mapfile-vers > It looks like the other entries are in alpha order so these > two new entries should also be added in alpha order. > > src/share/vm/prims/jvm.cpp > line 1510: return NULL; > nit: indent should be two spaces > > line 1529: assert(false, "cannot find method"); > line 1530: return NULL; // robustness > Normally "robustness" comments flag logic after an assert() > to indicate what we do in product mode to deal with the "bad" > situation without crashing. In this case, we don't try to use > 'm' after discovering that it is NULL so this could be simpler: > > Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); > assert(m != NULL, "cannot find method"); > return m; // caller has to deal with NULL in product mode > > Yes, I realize you only touched the comment here, but it > served to point out the messiness of the existing code. > > line 1551: return NULL; > line 1565: return NULL; > line 1579: return NULL; > nit: indent should be two spaces > > line 1632: return NULL; > line 1613: return NULL; > nit: indent should be two spaces > > src/share/vm/prims/jvm.h > No comments. > > >> >> Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009382 >> >> In short, this is needed in order to implement the desired semantics for reflecting over type annotations after a class redefine. This is also needed in order to reduce the size overhead introduces on the JDK side in the current type annotations reflection implementation. >> >> A prototype of the jdk changes can be found here: http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ > > You should use a separate bug ID for the jdk repo changes. This will > prevent confusion between when HSX with these changes is integrated > into JDK8 and when the jdk repo changes are integrated into JDK8. > > Dan > > > > >> >> While in the neighborhood I also fixed a handful of unlikely but possible null dereferences and removed an unused resource mark. I have run jdk_lang on a fastdebug build to verify the removal of the resource mark in addition to manual verification (also Dan helped me look into this, but errors are mine). >> >> For Oracle reviewers, ccc is approved. >> >> testing done: >> >> jdk_lang with and without my prototype jdk changes x product/fastdebug >> vm.quick.testlist >> jprt standard build and test >> >> cheers >> /Joel >> >> > From erik.joelsson at oracle.com Tue Mar 26 08:00:39 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Mar 2013 16:00:39 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <5151B817.30205@oracle.com> Joel, Looks good from the build group. /Erik On 2013-03-26 11:32, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = >> InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The > jdk changes shown are just a proof of concept, intended to highlight > that my HotSpot changes have actually been run. I will send out a > separate review request in the future for the JDK changes. > > cheers > /Joel From zhengyu.gu at oracle.com Tue Mar 26 08:13:01 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 26 Mar 2013 11:13:01 -0400 Subject: Review Request: 8010651 : create.bat still builds the kernel Message-ID: <5151BAFD.90003@oracle.com> This is the change to remove old kernel build targets and VS C++ projects created by create.bat. JBS: http://bugs.sun.com/view_bug.do?bug_id=8010651 Webrev: http://cr.openjdk.java.net/~zgu/8010651/webrev.00/ Thanks, -Zhengyu From gary.collins at oracle.com Tue Mar 26 10:03:46 2013 From: gary.collins at oracle.com (Gary Collins) Date: Tue, 26 Mar 2013 10:03:46 -0700 Subject: RFR: JDK-8009152 - OPEN - A number of jtreg tests need review/improvement In-Reply-To: <5137F499.3030908@oracle.com> References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> <5137F499.3030908@oracle.com> Message-ID: Applied changes Vladimir and Alan suggested. New webrev can be found here. http://cr.openjdk.java.net/~collins/8009152/webrev-01/ Please let me know if you see any issues with changes. Thanks Gary On Mar 6, 2013, at 5:59 PM, Vladimir Kozlov wrote: > test_env.sh should have Copyright header since it in open. Also there is duplicated java -version commands. I think first one at line 12 should be removed and the check (lines 14-18) moved after second one at line 77. > > Changes in tests scripts are fine. > > Thanks, > Vladimir > > On 3/6/13 4:43 PM, Gary Collins wrote: >> Request for Review >> >> Changes to allow better test utilization of jtreg hotspot regression tests >> 1: REPLACED JAVA_HOME with TESTJAVA >> 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. >> NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. >> NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) >> 3: Replaced most of the BIT_FLAG with TESTVMOPTS >> NOTE: This allows the tests where possible to run with multiple compilers and switches. Asked for by Quality team >> 4: Added TESTJAVACOPTS for all javac compile lines. Suggestion from tools folks. >> 5: Added a new shell env template. Phase 2 of hotspot test cleanup will utilize this file >> NOTE: This test_env.sh file will allow engineers to remove allot of the copy/paste of test setup from each shell testcase. >> 6: Fixed a gc testcase that was timing out on a 24 core box.. Simple fix , add a timeout. >> 7: I filed many bugs around native case issues. This changeset it not to address broken tests. Only to conform them in >> a unified way of running. >> 8: Fixing tests as defined above allows us to run the tests from a JRE. embedded use cases this is a stop gap. >> 9: In order to run jtreg with a JRE you need to define TESTJAVA (JRE - jdk/testjdk) & COMPILEJAVA (JDK - compilejdk) >> If TESTJAVA is a JDK no need to set COMPILEJAVA. >> NOTE: Most shell scripts from the command line may fail with the following issues: >> TESTSRC not defined, TESTCLASSES not defined, COMPILEJAVA path not found because we don't >> check for them at runtime. #5 above will fix this in the next phase of improving these tests to be more >> robust. >> >> Fully tested on linux-i586 builds with server/client jvm. >> >> Webrev: >> http://cr.openjdk.java.net/~collins/8009152/webrev-rev0/ >> >> Please let me know if you have any suggestions. >> Thanks >> Gary >> >> >> From coleen.phillimore at oracle.com Tue Mar 26 10:04:55 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Mar 2013 13:04:55 -0400 Subject: Review Request: 8010651 : create.bat still builds the kernel In-Reply-To: <5151BAFD.90003@oracle.com> References: <5151BAFD.90003@oracle.com> Message-ID: <5151D537.5050900@oracle.com> Looks good! Thanks for cleaning out the rest of the old kernel code. Coleen On 03/26/2013 11:13 AM, Zhengyu Gu wrote: > This is the change to remove old kernel build targets and VS C++ > projects created by create.bat. > > JBS: http://bugs.sun.com/view_bug.do?bug_id=8010651 > Webrev: http://cr.openjdk.java.net/~zgu/8010651/webrev.00/ > > > Thanks, > > -Zhengyu > From serguei.spitsyn at oracle.com Tue Mar 26 10:09:05 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Mar 2013 10:09:05 -0700 Subject: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition In-Reply-To: <515167AD.5040606@oracle.com> References: <513E8B88.6070904@oracle.com> <51515E3C.7040307@oracle.com> <515167AD.5040606@oracle.com> Message-ID: <5151D631.107@oracle.com> Hi David, Thank you for your opinion and concern on this! The removal of the NoSafepointVerifier is the biggest concern in this fix. It was raised in the preliminary review and already discussed a little bit. Now I hope to clear it up during the open code review. John wanted to look at it more closely but did not have enough time yet. Thanks, Serguei On 3/26/13 2:17 AM, David Holmes wrote: > Hi Serguei, > > The removal of the NoSafepointVerifier could be problematic. If that > method is never meant to be on the stack when you block for a > safepoint then the method is atomic with respect to the safepoint - > and so can not suffer interference from actions that occur at a > safepoint (like class unloading (?) ). Now I presume that somewhere > from that method you end up taking the mutex and so can block at a > safepoint (or block on the lock and so still allow a safepoint to > occur) - which might invalidate assumptions the method has about > "safepoint atomicity". > > You need to understand why the NSV was put there in the first place. > > David > ------ > > On 26/03/2013 6:37 PM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the following fix. >> The fix was preliminarily reviewed by Coleen, Christian >> and John but still a final and open jdk review is needed. >> So that, everyone is welcome to review the fix! >> >> This is open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ >> >> >> The CR is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 >> https://jbs.oracle.com/bugs/browse/JDK-8008511 >> >> >> The problem is that the old version of the bootstrap method is >> re-invoked >> after a popframe from the bootstrap method execution. >> It is because the MemberName keeps a stale reference to the old method >> version. >> >> The solution (suggested by John Rose) is to lazily create and keep >> up-to-date a MemberNameTable >> which plays a role of MemberName cache assosiated with the >> InstanceKlass. >> Then, at the Class redefinition, this cache is used to replace the old >> method >> references in the MemberName's with the new method references. >> >> The MemberNameTable is based on the GrowableArray. >> A C_HEAP array is allocated at the first call to >> InstanceKlass::add_member_name(). >> It is released in the InstanceKlass::release_C_heap_structures(). >> >> A global week reference to member name oop is stored in the >> MemberNameTable. >> It allowed to avoid having the oops_do() in the MemberNameTable. >> Also, the MemberNameTable won't hold member name oops in memory. >> >> The MemberNameTable_lock mutex is added to serialize MemberNameTable's >> updates. >> >> The following No_Safepoint_Verifier has been disabled: >> * src/share/vm/prims/methodHandles.cpp*: >> >> 799 int MethodHandles::find_MemberNames(Klass* k, >> . . . >> 803 DEBUG_ONLY(No_Safepoint_Verifier nsv); >> >> It is probably Ok, but, please, let me know if it is not. >> The assert related to locking is fired if it is not disabled. >> >> Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms >> (32 vs 64-bit too). >> The testing looks good so far. >> >> >> Thanks, >> Serguei >> >> From vladimir.kozlov at oracle.com Tue Mar 26 10:17:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Mar 2013 10:17:33 -0700 Subject: RFR: JDK-8009152 - OPEN - A number of jtreg tests need review/improvement In-Reply-To: References: <7B99E4E0-0902-4CC5-9AFA-81270FD77484@ORACLE.COM> <5137F499.3030908@oracle.com> Message-ID: <5151D82D.1060109@oracle.com> Looks good. Thanks, Vladimir On 3/26/13 10:03 AM, Gary Collins wrote: > Applied changes Vladimir and Alan suggested. > > New webrev can be found here. > http://cr.openjdk.java.net/~collins/8009152/webrev-01/ > > Please let me know if you see any issues with changes. > > Thanks > Gary > On Mar 6, 2013, at 5:59 PM, Vladimir Kozlov wrote: > >> test_env.sh should have Copyright header since it in open. Also there is duplicated java -version commands. I think first one at line 12 should be removed and the check (lines 14-18) moved after second one at line 77. >> >> Changes in tests scripts are fine. >> >> Thanks, >> Vladimir >> >> On 3/6/13 4:43 PM, Gary Collins wrote: >>> Request for Review >>> >>> Changes to allow better test utilization of jtreg hotspot regression tests >>> 1: REPLACED JAVA_HOME with TESTJAVA >>> 2: REPLACED TESTJAVA with COMPILEJAVA Some tests needed tools like (javac,jar,path to native libraries) to run. >>> NOTE: THIS IS NEEDED WHEN TESTJAVA is a JRE. If TESTJAVA is a JDK then COMPILEJAVA is not needed. >>> NOTE: FALLBACK when COMPILEJAVA is not defined for JTREG is TESTJAVA (with implied JDK being tested) >>> 3: Replaced most of the BIT_FLAG with TESTVMOPTS >>> NOTE: This allows the tests where possible to run with multiple compilers and switches. Asked for by Quality team >>> 4: Added TESTJAVACOPTS for all javac compile lines. Suggestion from tools folks. >>> 5: Added a new shell env template. Phase 2 of hotspot test cleanup will utilize this file >>> NOTE: This test_env.sh file will allow engineers to remove allot of the copy/paste of test setup from each shell testcase. >>> 6: Fixed a gc testcase that was timing out on a 24 core box.. Simple fix , add a timeout. >>> 7: I filed many bugs around native case issues. This changeset it not to address broken tests. Only to conform them in >>> a unified way of running. >>> 8: Fixing tests as defined above allows us to run the tests from a JRE. embedded use cases this is a stop gap. >>> 9: In order to run jtreg with a JRE you need to define TESTJAVA (JRE - jdk/testjdk) & COMPILEJAVA (JDK - compilejdk) >>> If TESTJAVA is a JDK no need to set COMPILEJAVA. >>> NOTE: Most shell scripts from the command line may fail with the following issues: >>> TESTSRC not defined, TESTCLASSES not defined, COMPILEJAVA path not found because we don't >>> check for them at runtime. #5 above will fix this in the next phase of improving these tests to be more >>> robust. >>> >>> Fully tested on linux-i586 builds with server/client jvm. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~collins/8009152/webrev-rev0/ >>> >>> Please let me know if you have any suggestions. >>> Thanks >>> Gary >>> >>> >>> > From staffan.larsen at oracle.com Tue Mar 26 11:20:33 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Mar 2013 19:20:33 +0100 Subject: Review Request: 8010651 : create.bat still builds the kernel In-Reply-To: <5151BAFD.90003@oracle.com> References: <5151BAFD.90003@oracle.com> Message-ID: Looks good! On 26 mar 2013, at 16:13, Zhengyu Gu wrote: > This is the change to remove old kernel build targets and VS C++ projects created by create.bat. > > JBS: http://bugs.sun.com/view_bug.do?bug_id=8010651 > Webrev: http://cr.openjdk.java.net/~zgu/8010651/webrev.00/ > > > Thanks, > > -Zhengyu > From zhengyu.gu at oracle.com Tue Mar 26 11:25:30 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 26 Mar 2013 14:25:30 -0400 Subject: Review Request: 8010651 : create.bat still builds the kernel In-Reply-To: References: <5151BAFD.90003@oracle.com> Message-ID: <5151E81A.3080807@oracle.com> Thanks for reviewing. -Zhengyu On 3/26/2013 2:20 PM, Staffan Larsen wrote: > Looks good! > > On 26 mar 2013, at 16:13, Zhengyu Gu wrote: > >> This is the change to remove old kernel build targets and VS C++ projects created by create.bat. >> >> JBS: http://bugs.sun.com/view_bug.do?bug_id=8010651 >> Webrev: http://cr.openjdk.java.net/~zgu/8010651/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu >> From zhengyu.gu at oracle.com Tue Mar 26 11:25:42 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 26 Mar 2013 14:25:42 -0400 Subject: Review Request: 8010651 : create.bat still builds the kernel In-Reply-To: <5151D537.5050900@oracle.com> References: <5151BAFD.90003@oracle.com> <5151D537.5050900@oracle.com> Message-ID: <5151E826.9050005@oracle.com> Thanks, -Zhengyu On 3/26/2013 1:04 PM, Coleen Phillimore wrote: > > Looks good! Thanks for cleaning out the rest of the old kernel code. > Coleen > > On 03/26/2013 11:13 AM, Zhengyu Gu wrote: >> This is the change to remove old kernel build targets and VS C++ >> projects created by create.bat. >> >> JBS: http://bugs.sun.com/view_bug.do?bug_id=8010651 >> Webrev: http://cr.openjdk.java.net/~zgu/8010651/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu >> > From joel.franck at oracle.com Tue Mar 26 23:47:40 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 27 Mar 2013 07:47:40 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> Message-ID: Thanks Rickard, Dan and Erik for the reviews and help with pushing this. cheers /Joel On 26 mar 2013, at 15:40, Rickard B?ckman wrote: > I'll sponsor the change. > > /R > > On Mar 25, 2013, at 4:17 PM, Daniel D. Daugherty wrote: > >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: >>> Hi, >>> >>> Please review: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.01/ >> >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces >> >> src/share/vm/prims/jvm.h >> No comments. >> >> >>> >>> Bug is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009382 >>> >>> In short, this is needed in order to implement the desired semantics for reflecting over type annotations after a class redefine. This is also needed in order to reduce the size overhead introduces on the JDK side in the current type annotations reflection implementation. >>> >>> A prototype of the jdk changes can be found here: http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> >> Dan >> >> >> >> >>> >>> While in the neighborhood I also fixed a handful of unlikely but possible null dereferences and removed an unused resource mark. I have run jdk_lang on a fastdebug build to verify the removal of the resource mark in addition to manual verification (also Dan helped me look into this, but errors are mine). >>> >>> For Oracle reviewers, ccc is approved. >>> >>> testing done: >>> >>> jdk_lang with and without my prototype jdk changes x product/fastdebug >>> vm.quick.testlist >>> jprt standard build and test >>> >>> cheers >>> /Joel >>> >>> >> > From rickard.backman at oracle.com Wed Mar 27 02:24:05 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 27 Mar 2013 09:24:05 +0000 Subject: hg: hsx/hsx24/hotspot: 8008357: [sampling] assert(sender_blob->is_runtime_stub() || sender_blob->is_nmethod()) failed: Impossible call chain Message-ID: <20130327092421.455994840F@hg.openjdk.java.net> Changeset: bec5f1758368 Author: rbackman Date: 2013-02-28 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bec5f1758368 8008357: [sampling] assert(sender_blob->is_runtime_stub() || sender_blob->is_nmethod()) failed: Impossible call chain Reviewed-by: coleenp, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp From jesper.wilhelmsson at oracle.com Wed Mar 27 09:04:19 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 27 Mar 2013 17:04:19 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <51531883.7070903@oracle.com> Hi, A new webrev is now available. The issues reported from the first review should be fixed and the project now contains configurations for both Linux_64 and Mac_64. To select configuration there is a dropdown menu next to the build button. http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ Thanks, /Jesper Jesper Wilhelmsson skrev 25/3/13 5:29 PM: > Hi, > > Sorry for cross posting, but I think this could be useful for several areas. > > I would like to add Solaris Studio / NetBeans project files for the entire > OpenJDK project. To clarify: One project that contains the entire OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly > fast and even though I personally mostly work in the HotSpot tree, I tend to > always clone and build the entire JDK forest. I find this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper From peter.allwin at oracle.com Wed Mar 27 09:29:29 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 27 Mar 2013 17:29:29 +0100 Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM Message-ID: <51531E69.7040000@oracle.com> Webrev: http://cr.openjdk.java.net/~sla/peter/8002118/webrev.01/ CR: http://bugs.sun.com/view_bug.do?bug_id=8002118 https://jbs.oracle.com/bugs/browse/JDK-8002118 Problem is that on Windows we probe for dbghelp.dll on a number of different places, and that list always included \Program Files\Debugging Tools for Windows (x64) even if we're running x86, leading to an UnsatisfiedLinkError during load. Fix is to add the ...(x64) path only if we're on amd64, and ...(x86) only if we're on x86. The affected tests have been verified to work with this fix. Thanks to Staffan for helping out and hosting the webrev! Regards, /peter From zhengyu.gu at oracle.com Wed Mar 27 10:03:47 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 27 Mar 2013 13:03:47 -0400 Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM In-Reply-To: <51531E69.7040000@oracle.com> References: <51531E69.7040000@oracle.com> Message-ID: <51532673.4040705@oracle.com> Looks good to me. -Zhengyu On 3/27/2013 12:29 PM, Peter Allwin wrote: > Webrev: > http://cr.openjdk.java.net/~sla/peter/8002118/webrev.01/ > > CR: > http://bugs.sun.com/view_bug.do?bug_id=8002118 > https://jbs.oracle.com/bugs/browse/JDK-8002118 > > > Problem is that on Windows we probe for dbghelp.dll on a number of > different places, and that list always included \Program > Files\Debugging Tools for Windows (x64) even if we're running x86, > leading to an UnsatisfiedLinkError during load. > > Fix is to add the ...(x64) path only if we're on amd64, and ...(x86) > only if we're on x86. The affected tests have been verified to work > with this fix. > > > Thanks to Staffan for helping out and hosting the webrev! > > Regards, > > /peter > > From zhengyu.gu at oracle.com Wed Mar 27 10:47:44 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 27 Mar 2013 13:47:44 -0400 Subject: Review request: 8010474 [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp In-Reply-To: <515313B9.2070200@oracle.com> References: <515313B9.2070200@oracle.com> Message-ID: <515330C0.6030907@oracle.com> Resend to open JDK for public review. Simple fixes to those dummy functions that miss return values. JBS: https://jbs.oracle.com/bugs/browse/JDK-8010474 Webrev: http://cr.openjdk.java.net/~zgu/8010474/webrev.00/ Thanks, -Zhengyu From vladimir.kozlov at oracle.com Wed Mar 27 11:07:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Mar 2013 11:07:23 -0700 Subject: Review request: 8010474 [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp In-Reply-To: <515330C0.6030907@oracle.com> References: <515313B9.2070200@oracle.com> <515330C0.6030907@oracle.com> Message-ID: <5153355B.5000104@oracle.com> Good. Thanks, Vladimir On 3/27/13 10:47 AM, Zhengyu Gu wrote: > Resend to open JDK for public review. > > Simple fixes to those dummy functions that miss return values. > > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8010474 > Webrev: http://cr.openjdk.java.net/~zgu/8010474/webrev.00/ > > Thanks, > > -Zhengyu > > > From serguei.spitsyn at oracle.com Wed Mar 27 11:32:29 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Mar 2013 11:32:29 -0700 Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM In-Reply-To: <51531E69.7040000@oracle.com> References: <51531E69.7040000@oracle.com> Message-ID: <51533B3D.8000503@oracle.com> Hi Peter, The fix looks good. Thanks, Serguei On 3/27/13 9:29 AM, Peter Allwin wrote: > Webrev: > http://cr.openjdk.java.net/~sla/peter/8002118/webrev.01/ > > CR: > http://bugs.sun.com/view_bug.do?bug_id=8002118 > https://jbs.oracle.com/bugs/browse/JDK-8002118 > > > Problem is that on Windows we probe for dbghelp.dll on a number of > different places, and that list always included \Program > Files\Debugging Tools for Windows (x64) even if we're running x86, > leading to an UnsatisfiedLinkError during load. > > Fix is to add the ...(x64) path only if we're on amd64, and ...(x86) > only if we're on x86. The affected tests have been verified to work > with this fix. > > > Thanks to Staffan for helping out and hosting the webrev! > > Regards, > > /peter > > From karen.kinnear at oracle.com Wed Mar 27 12:04:52 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 27 Mar 2013 15:04:52 -0400 Subject: Review request: 8010474 [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp In-Reply-To: <5153355B.5000104@oracle.com> References: <515313B9.2070200@oracle.com> <515330C0.6030907@oracle.com> <5153355B.5000104@oracle.com> Message-ID: <5EF545B6-36AD-404B-AFD9-759A3DD91B15@oracle.com> Changes look good. thanks, Karen On Mar 27, 2013, at 2:07 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 3/27/13 10:47 AM, Zhengyu Gu wrote: >> Resend to open JDK for public review. >> >> Simple fixes to those dummy functions that miss return values. >> >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8010474 >> Webrev: http://cr.openjdk.java.net/~zgu/8010474/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> >> >> From zhengyu.gu at oracle.com Wed Mar 27 12:13:03 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 27 Mar 2013 15:13:03 -0400 Subject: Review request: 8010474 [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp In-Reply-To: <5153355B.5000104@oracle.com> References: <515313B9.2070200@oracle.com> <515330C0.6030907@oracle.com> <5153355B.5000104@oracle.com> Message-ID: <515344BF.5020607@oracle.com> Thanks! -Zhengyu On 3/27/2013 2:07 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 3/27/13 10:47 AM, Zhengyu Gu wrote: >> Resend to open JDK for public review. >> >> Simple fixes to those dummy functions that miss return values. >> >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8010474 >> Webrev: http://cr.openjdk.java.net/~zgu/8010474/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> >> >> From zhengyu.gu at oracle.com Wed Mar 27 14:24:31 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 27 Mar 2013 21:24:31 +0000 Subject: hg: hsx/hsx24/hotspot: 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT; ... Message-ID: <20130327212436.9B11848430@hg.openjdk.java.net> Changeset: a1b2802cb232 Author: zgu Date: 2013-03-27 14:48 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a1b2802cb232 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT 8009777: NMT: add new NMT dcmd to control auto shutdown option Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation Reviewed-by: dcubed, coleenp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp From christian.tornqvist at oracle.com Wed Mar 27 14:52:12 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 27 Mar 2013 22:52:12 +0100 Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM In-Reply-To: <51531E69.7040000@oracle.com> References: <51531E69.7040000@oracle.com> Message-ID: <015101ce2b35$57bcdfe0$07369fa0$@tornqvist@oracle.com> I'm quite certain there will never be a \Program Files (x64)\. On 64bit systems there's \Program Files\ and \Program Files (x86)\, on a 32bit systems there will only be a \Program Files\. So it would make sense to add \Program Files (x86)\ if we're running a 32bit JVM since we might be on a 64bit version of Windows. Thanks, Christian -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Peter Allwin Sent: den 27 mars 2013 17:29 To: serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM Webrev: http://cr.openjdk.java.net/~sla/peter/8002118/webrev.01/ CR: http://bugs.sun.com/view_bug.do?bug_id=8002118 https://jbs.oracle.com/bugs/browse/JDK-8002118 Problem is that on Windows we probe for dbghelp.dll on a number of different places, and that list always included \Program Files\Debugging Tools for Windows (x64) even if we're running x86, leading to an UnsatisfiedLinkError during load. Fix is to add the ...(x64) path only if we're on amd64, and ...(x86) only if we're on x86. The affected tests have been verified to work with this fix. Thanks to Staffan for helping out and hosting the webrev! Regards, /peter From serguei.spitsyn at oracle.com Wed Mar 27 16:45:04 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Mar 2013 16:45:04 -0700 Subject: hs25 review request: 8007037 JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Message-ID: <51538480.4010504@oracle.com> Please, review the hs25 fix below. Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.1/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007037 https://jbs.oracle.com/bugs/browse/JDK-8007037 References from INDY bootstrap method specifier operands to CP entries and back must be correctly merged at class redefinition. Some background. An invokedynamic bytecode spec: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokedynamic A invokedynamic instruction has an argument which is an index to the *Constant Pool* item. That index must be a symbolic reference to a *call-site specifier*: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.10 A CP item of the type *CONSTANT_InvokeDynamic_inf* has an index into the *bootstrap method attribute* of the class file: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.21 The *|BootstrapMethods|* attribute elements normally have references to other *Constant Pool* items. In VM the *bootstrap method attribute* is represented by the *operands* array of the *ConstantPool*. The problem is is that all the force and back cross links between *ConstantPool* elements and *operands* array elements must be correctly merged at class redefinition. Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. One difficulty is that new vm.mlvm tests are currently failed because of multiple reasons. Thanks, Serguei From daniel.daugherty at oracle.com Wed Mar 27 18:21:45 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 28 Mar 2013 01:21:45 +0000 Subject: hg: hsx/hotspot-main/hotspot: 22 new changesets Message-ID: <20130328012232.0EB3F48443@hg.openjdk.java.net> Changeset: eca90b8a06eb Author: rdurbin Date: 2013-03-19 11:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eca90b8a06eb 7030610: runtime/6878713/Test6878713.sh fails Error. failed to clean up files after test 7123945: runtime/6878713/Test6878713.sh require about 2G of native memory, swaps and times out Summary: Add new diagnostic option -XX:MallocMaxTestWords=NNN and fix Test6878713.sh. Reviewed-by: dcubed, coleenp, dholmes, iklam ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! test/runtime/6878713/Test6878713.sh Changeset: a649f6511c04 Author: ctornqvi Date: 2013-03-20 08:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a649f6511c04 8010084: Race in runtime/NMT/BaselineWithParameter.java Summary: Added a waitFor() on the process Reviewed-by: mgerdin, sla, zgu ! test/runtime/NMT/BaselineWithParameter.java Changeset: 91bf0bdae37b Author: coleenp Date: 2013-03-20 08:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91bf0bdae37b 8008217: CDS: Class data sharing limits the malloc heap on Solaris Summary: In 64bit VM move CDS archive address to 32G on all platforms using new flag SharedBaseAddress. In 32bit VM set CDS archive address to 3Gb on Linux and let other OSs pick the address. Reviewed-by: kvn, dcubed, zgu, hseigel ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2c7663baeb67 Author: acorn Date: 2013-03-20 11:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c7663baeb67 8010017: lambda: reflection get(Declared)Methods support for default methods. Summary: Don't expose vm generated overpass (bridges to default methods). Reviewed-by: dholmes, fparain ! src/share/vm/prims/jvm.cpp Changeset: 79259e97a072 Author: acorn Date: 2013-03-20 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79259e97a072 Merge Changeset: 1feda2e9f044 Author: ctornqvi Date: 2013-03-20 20:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1feda2e9f044 8007982: some runtime/CommandLine/ tests fail on 32-bit platforms Summary: Changed tests to use platform independent flags Reviewed-by: collins, hseigel, zgu ! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java ! test/runtime/CommandLine/FlagWithInvalidValue.java ! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java Changeset: 81d1b58c078f Author: rdurbin Date: 2013-03-20 20:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81d1b58c078f 8010396: checking MallocMaxTestWords in testMalloc() function is redundant Summary: Remove redundant checks in testMalloc and add assert. Reviewed-by: dcubed, coleenp, dholmes ! src/share/vm/runtime/os.cpp Changeset: e7081eb7e786 Author: dcubed Date: 2013-03-20 20:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7081eb7e786 Merge Changeset: 06db4c0afbf3 Author: zgu Date: 2013-03-20 09:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/06db4c0afbf3 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT 8009777: NMT: add new NMT dcmd to control auto shutdown option Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation Reviewed-by: dcubed, coleenp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 0ac03fef364f Author: zgu Date: 2013-03-21 06:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0ac03fef364f Merge ! src/share/vm/runtime/globals.hpp Changeset: 14509df4cd63 Author: iklam Date: 2013-03-21 20:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/14509df4cd63 8010389: After fix for 7107135 a failed dlopen() call results in a VM crash Summary: Call dlerror() in VM thread as necessary. Reviewed-by: coleenp, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp + test/runtime/8010389/VMThreadDlopen.java Changeset: 6574f999e0cf Author: dcubed Date: 2013-03-23 22:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6574f999e0cf Merge ! src/share/vm/memory/metaspace.cpp Changeset: c342fbdf8a70 Author: ctornqvi Date: 2013-03-24 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c342fbdf8a70 8008454: test/runtime/NMT/PrintNMTStatistics is broken Summary: Added @run tag so that it actually runs the test, also fixed broken command line and incorrect parsing. Also reviewed by gerard.ziemski at oracle.com Reviewed-by: mgerdin, zgu ! test/runtime/NMT/PrintNMTStatistics.java Changeset: 9c8e53c7bed0 Author: ctornqvi Date: 2013-03-24 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9c8e53c7bed0 Merge - make/test/Queens.java Changeset: 729be16a470b Author: hseigel Date: 2013-03-25 08:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/729be16a470b 8010667: Non-zero padding is not allowed in splitverifier for tableswitch/lookupswitch instructions. Summary: Don't check the padding bits if class file version is >= 51. Reviewed-by: kvn, dholmes, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b8deb3205b51 Author: bharadwaj Date: 2013-03-25 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b8deb3205b51 8009552: test/vm/verifier/TestStaticIF.java failing with hs25.0-b Summary: Remove support for verification of class files with version 52 and above from type inference verifier. Reviewed-by: acorn, hseigel ! src/share/vm/classfile/verifier.cpp - test/runtime/8007736/TestStaticIF.java Changeset: 1916ca1dec2f Author: rbackman Date: 2013-03-26 15:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1916ca1dec2f 8009382: Add JVM_Get{Field|Method}TypeAnnotations Reviewed-by: dcubed, rbackman Contributed-by: Joel Borggren-Franck ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 36376b540a98 Author: hseigel Date: 2013-03-26 09:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/36376b540a98 8009595: The UseSplitVerifier option needs to be deprecated. Summary: Put UseSplitVerifier option on the deprecated list. Reviewed-by: dcubed, kmo, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a8016373a893 Author: hseigel Date: 2013-03-26 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a8016373a893 Merge Changeset: 6b748c9e1845 Author: zgu Date: 2013-03-26 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b748c9e1845 8010651: create.bat still builds the kernel Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows Reviewed-by: coleenp, sla ! make/windows/build.make ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/product.make ! make/windows/makefiles/vm.make - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java Changeset: 85192022ba8c Author: zgu Date: 2013-03-26 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85192022ba8c Merge - test/runtime/8007736/TestStaticIF.java Changeset: 23f2d309e855 Author: zgu Date: 2013-03-26 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23f2d309e855 Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw From vladimir.kozlov at oracle.com Wed Mar 27 22:48:17 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 28 Mar 2013 05:48:17 +0000 Subject: hg: hsx/hsx24/hotspot: 22 new changesets Message-ID: <20130328054906.B32EC48452@hg.openjdk.java.net> Changeset: 399bb8104fea Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/399bb8104fea 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: c638b7564d34 Author: vlivanov Date: 2013-02-01 03:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c638b7564d34 8005439: no message about inline method if it specifed by CompileCommand Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: c605c1bd2819 Author: drchase Date: 2013-01-25 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c605c1bd2819 8006500: compiler/8004741/Test8004741.java fails intermediately Summary: rewrote the test to be more reliable, add test for invalid size exception Reviewed-by: kvn ! test/compiler/8004741/Test8004741.java Changeset: 19a6982e2d05 Author: mikael Date: 2013-02-04 10:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/19a6982e2d05 8007403: Incorrect format arguments in adlparse.cpp Reviewed-by: kvn, twisti ! src/share/vm/adlc/adlparse.cpp Changeset: 9fdfc60415f1 Author: vlivanov Date: 2013-02-05 08:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9fdfc60415f1 8006613: adding reason to made_not_compilable Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 1efffc8cd1e5 Author: drchase Date: 2013-02-06 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1efffc8cd1e5 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Summary: check ndimensions before accessing length[i] element Reviewed-by: kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/parse3.cpp Changeset: c56c6ba9c1d2 Author: kvn Date: 2013-02-08 15:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c56c6ba9c1d2 8007708: compiler/6855215 assert(VM_Version::supports_sse4_2()) Summary: Added missing UseSSE42 check. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 71a67ff5e673 Author: drchase Date: 2013-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/71a67ff5e673 8007402: Code cleanup to remove Parfait false positive Summary: add array access range check Reviewed-by: kvn ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: 1c0be805666b Author: kmo Date: 2013-02-10 22:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1c0be805666b 8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked() Reviewed-by: kvn ! src/share/vm/runtime/globals.cpp Changeset: 36b32e7ee4f7 Author: roland Date: 2013-02-12 12:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/36b32e7ee4f7 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Summary: Add support for expensive nodes. Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.hpp Changeset: 3eea57ac42f2 Author: kmo Date: 2013-02-12 07:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3eea57ac42f2 8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled Reviewed-by: jrose ! test/compiler/7009359/Test7009359.java Changeset: 95f5d78a4bc1 Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/95f5d78a4bc1 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 53dd0089983e Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/53dd0089983e 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: b1c0da991402 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b1c0da991402 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: be30099fbdec Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be30099fbdec 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 2faf0eecd402 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2faf0eecd402 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: bb4db1d23cba Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bb4db1d23cba 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 194355f552ff Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/194355f552ff 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: abc47675c9e2 Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/abc47675c9e2 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: 979e7c5df753 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/979e7c5df753 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: e388232ba684 Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e388232ba684 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 539375f92462 Author: bharadwaj Date: 2013-03-22 07:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/539375f92462 8009539: JVM crash when run lambda testng tests Summary: Ensure class pointer is non-null before dereferencing it to check if it is loaded. Reviewed-by: kvn ! src/share/vm/opto/parse2.cpp From bengt.rutisson at oracle.com Thu Mar 28 06:35:54 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 28 Mar 2013 13:35:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130328133610.508CA48468@hg.openjdk.java.net> Changeset: 7f16d1812865 Author: tamao Date: 2013-03-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f16d1812865 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Summary: Remove the related assertions becasue they do not hold here. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp Changeset: dbd5837b342f Author: ehelin Date: 2013-03-22 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dbd5837b342f 8000754: NPG: Implement a MemoryPool MXBean for Metaspace Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: 338b3a9e29b5 Author: stefank Date: 2013-03-25 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/338b3a9e29b5 Merge ! src/share/vm/services/memoryService.cpp Changeset: 42e370795a39 Author: ehelin Date: 2013-03-27 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/42e370795a39 8010818: NPG: Remove metaspace memory pools Reviewed-by: mgerdin, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp - test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: aeb22fdaa14c Author: brutisso Date: 2013-03-28 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aeb22fdaa14c Merge ! src/share/vm/runtime/arguments.cpp From mikael.vidstedt at oracle.com Thu Mar 28 09:40:34 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Mar 2013 09:40:34 -0700 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <5126E2FE.9060200@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> <51251015.5000501@oracle.com> <51267CE4.6090104@oracle.com> <5126E2FE.9060200@oracle.com> Message-ID: <51547282.6090005@oracle.com> I've been waiting for Joe's changes to bubble up so as to not add a conflict unnecessarily, and since they're now in hotspot-rt I have uploaded a webrev for what I hope is a final time *knocking on wood*. I would appreciate a quick check to see that everything still looks fine: http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.08/webrev/ The only relevant changes from the last webrev should be: make/linux/makefiles/gcc.make: * Eliminate the ADDITIONAL_WARNINGS variable and just use WARNING_FLAGS directly * Clean up the -Wconversion logic src/share/vm/runtime/arguments.cpp: * Updated after the recent changes to SERIAL/INCLUDE_ALL_GCS (8005915) Thanks, Mikael On 2/21/2013 7:16 PM, David Holmes wrote: > One final comment - please liaise with Joe Provino who is adding > -Wundef so we can get a consistent approach as to where these -Wxxx > flags get added. :) > > > (Don't know what I was looking at with the trace_locking stuff - it > ends up as an empty method.) > > David > > On 22/02/2013 6:00 AM, Mikael Vidstedt wrote: >> >> On 2013-02-20 10:04, Coleen Phillimore wrote: >>> On 2/20/2013 12:33 PM, Mikael Vidstedt wrote: >>>> >>>> On 2/19/2013 12:01 PM, Christian Thalinger wrote: >>>>> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >>>>> wrote: >>>>> >>>>>> A really good control question, thanks a lot for asking! >>>>>> >>>>>> As a matter of fact these changes are basically just doing what the >>>>>> compiler already does for us, so it's more about cleaning up the >>>>>> source code than reducing the size of the binary. So in theory >>>>>> these changes should have no impact on the binary size at all, but >>>>>> it actually turns out they do. Very specifically, the fact that I >>>>>> moved the same_page() function from being duplicated in the three >>>>>> os_.cpp files to having it be in globalDefinitions.cpp makes >>>>>> the binary grow a few bytes (54 bytes to be specific). The reason >>>>>> is a bit subtle: >>>>>> >>>>>> The same_page() function is (was) static in the respective os_*.cpp >>>>>> files. They are only ever used when the Verbose flag is true, and >>>>>> furthermore the Verbose option is a develop only flag, which means >>>>>> it is hardcoded to false in product. The compiler knows that's the >>>>>> case and eliminates the same_page() function completely. >>>>>> >>>>>> Since I moved it to globalDefinitions.cpp there's no way easy for >>>>>> the compiler to know that it is not being used, so it will actually >>>>>> keep the function. >>>>>> >>>>>> Unless there are strong opinions I'm not going to do anything about >>>>>> this. >>>>>> >>>>>> However, this made me question my earlier experiments with using >>>>>> the const bool = false construct in constantPool.cpp, because after >>>>>> all that is the exact same pattern. And it turns out that I must >>>>>> have done something wrong when I was performing the experiments, >>>>>> because when I do the same thing again now it turns out the >>>>>> compiler actually *does* deadcode eliminate the debug-only >>>>>> functions. So I take everything back and conclude that const bool = >>>>>> false is indeed a great way to make sure the debug code does not >>>>>> rot over time, and that the product binary will *not* contain the >>>>>> dead functions. Sorry for any confusion this may have caused. >>>>>> >>>>>> With all that in mind, here's another version of the webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >>>>> src/share/vm/interpreter/interpreterRuntime.cpp: >>>>> >>>>> I suppose that #if 0 is to keep that code for...? Could we add a >>>>> comment why we keep it? >>>> >>>> This was by "popular request" (from David Holmes) :) >>>> >>>> I personally don't know if and how this is being used. Note that >>>> ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the >>>> non-product implementation in synchronizer.cpp is empty (modulo the >>>> comment saying "Don't know what to do here"), so one can question the >>>> value of keeping the any of the trace_locking functions, but they may >>>> be someone's favorite debugging tool. Until proven differently I will >>>> leave it in there for now. If somebody can help me provide a useful >>>> comment about how the code is actually being used then I will >>>> certainly add it, otherwise I'll keep this as it is. >>> >>> If I remember correctly, this trace_locking code was associated with a >>> flag that we removed a long time ago. I don't think if we want to >>> implement TraceLocking we'd use this function. My vote is that it and >>> the ObjectMonitor:: version should be removed. >> >> Thanks Coleen, that makes sense. I've prepared a final version of the >> webrev with the trace_locking methods removed too: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.06/webrev/ >> >> Any final comments? >> >> Cheers, >> Mikael >> >>> >>> Coleen >>>> >>>>> src/share/vm/oops/constantPool.cpp: >>>>> >>>>> So we use: >>>>> >>>>> + const bool debug_cpool = false; >>>>> >>>>> but we still have the DBG macro. Can't we have a static debug >>>>> method that takes all printf arguments and prints them? The >>>>> debug_cpool should make that method empty and the compiler can >>>>> remove it. I really start to hate all these macros... >>>> >>>> I share your macro hate and I actually played around with removing >>>> the macros just as you say. There is one small problem with doing it >>>> that way, and that's the fact that a few of the printf:s print >>>> symbols names, and as part of that they need to create utf8 strings >>>> using sym->as_utf8(). The compiler can unfortunately not know that >>>> that function is for all intents and purposes a no-op, so it will >>>> keep the call even in product meaning increased binary size and it >>>> will also add to the runtime since it actually performs the call and >>>> creates the utf8 string. So I'm going to keep the macros for now. >>>> >>>> >>>> I also moved the clamp_address_in_page to the globalDefinitions.hpp >>>> header file, meaning it will be inlined and dead code eliminated. >>>> >>>> New webrev here: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ >>>> >>>> Final comments? >>>> >>>> Cheers, >>>> Mikael >>>> >>> >> From adomurad at redhat.com Thu Mar 28 12:02:45 2013 From: adomurad at redhat.com (Adam Domurad) Date: Thu, 28 Mar 2013 15:02:45 -0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <513E1210.4030406@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> <5130D0AB.8000001@oracle.com> <513780C0.9050103@redhat.com> <513E1210.4030406@oracle.com> Message-ID: <515493D5.7090308@redhat.com> On 03/11/2013 01:19 PM, Dmitry Samersoff wrote: > Adam, > > Sorry! I can't provide any estimations right now. But it's a high > priority issue in my queue, and I plan to provide a fix as soon as it > become possible. > > -Dmitry > > On 2013-03-06 21:45, Adam Domurad wrote: >> On 03/01/2013 11:00 AM, Dmitry Samersoff wrote: >>> Adam, >>> >>> Thank you for advice! I'm looking for a possibility to remove >>> get_stack_bounds function entirely as Dean suggested. But it takes some >>> time. >> Hi again, not to be a bother, but do you have a rough time-frame that >> the fix will take? >> >> Thanks, >> -Adam > As per our off-list chat, I have attached my implementation of a revised implementation of get_stack_bounds with a small test-case. As far as performance is concerned, it's an order of magnitude faster from my timings. This should be suitable given that no problems were reported with the old implementation. Happy hacking, -Adam -------------- next part -------------- #include #include #include #include #include #include typedef int bool; #define false 0 #define true 1 static bool get_stack_bounds(uintptr_t *bottom, uintptr_t *top) { int fd = open("/proc/self/maps", O_RDONLY); if (fd < 0) { return false; } int line_len = 0; /* Length of partially copied line portion */ const int BUFFER_SIZE = 256; /* Comfortable upper bound on possible line size */ char buffer[BUFFER_SIZE]; bool success = false; for (;;) { int read_len = read(fd, buffer + line_len, BUFFER_SIZE - line_len - 1); if (read_len <= 0) { break; /* Fail */ } char *buffer_end = buffer + line_len + read_len; *buffer_end = '\0'; /* Null-terminate for string functions */ const char *stack_loc = strstr(buffer, "[stack]"); /* We either find '[stack]', or we try to complete the last line */ const char *line_end = stack_loc ? stack_loc : buffer_end; const char *line_start = line_end; /* Find start of line */ while (line_start > buffer && line_start[-1] != '\n') { line_start--; } if (stack_loc) { if (sscanf(line_start, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { uintptr_t sp = (uintptr_t) __builtin_frame_address(0); success = (sp >= *bottom && sp <= *top); } break; /* Succeed if we parsed valid stack bounds */ } line_len = line_end - line_start; if (line_len >= BUFFER_SIZE - 1) { break; /* Line too large, fail */ } memcpy(buffer, line_start, line_len); } close(fd); return success; } int main(void) { bool something_failed = false; int i; for (i = 2; i <= 1024 * 4; i++) { uintptr_t bottom, top; bool success = get_stack_bounds(&bottom, &top); if (!success) { something_failed = true; printf("FAILED FOR %d\n", i); } } if (!something_failed) { printf("All success\n"); } return 0; } From dmitry.samersoff at oracle.com Thu Mar 28 12:05:57 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 28 Mar 2013 23:05:57 +0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <515493D5.7090308@redhat.com> References: <512CF7D5.2030300@redhat.com> <512D2B73.4060103@oracle.com> <5130D0AB.8000001@oracle.com> <513780C0.9050103@redhat.com> <513E1210.4030406@oracle.com> <515493D5.7090308@redhat.com> Message-ID: <51549495.6000603@oracle.com> Adam, Thank you! -Dmitry On 2013-03-28 23:02, Adam Domurad wrote: > On 03/11/2013 01:19 PM, Dmitry Samersoff wrote: >> Adam, >> >> Sorry! I can't provide any estimations right now. But it's a high >> priority issue in my queue, and I plan to provide a fix as soon as it >> become possible. >> >> -Dmitry >> >> On 2013-03-06 21:45, Adam Domurad wrote: >>> On 03/01/2013 11:00 AM, Dmitry Samersoff wrote: >>>> Adam, >>>> >>>> Thank you for advice! I'm looking for a possibility to remove >>>> get_stack_bounds function entirely as Dean suggested. But it takes some >>>> time. >>> Hi again, not to be a bother, but do you have a rough time-frame that >>> the fix will take? >>> >>> Thanks, >>> -Adam >> > > As per our off-list chat, I have attached my implementation of a revised > implementation of get_stack_bounds with a small test-case. As far as > performance is concerned, it's an order of magnitude faster from my > timings. This should be suitable given that no problems were reported > with the old implementation. > > Happy hacking, > -Adam -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From alejandro.murillo at oracle.com Thu Mar 28 14:33:35 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 28 Mar 2013 21:33:35 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130328213344.1464B48479@hg.openjdk.java.net> Changeset: 52e13c42fab4 Author: katleman Date: 2013-03-27 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/52e13c42fab4 Added tag jdk7u14-b18 for changeset 72e4bc0bcbd2 ! .hgtags Changeset: 795212ad5b1b Author: amurillo Date: 2013-03-28 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/795212ad5b1b Merge - src/share/vm/gc_implementation/shared/promotionFailedInfo.hpp Changeset: 5e622bdc713e Author: amurillo Date: 2013-03-28 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e622bdc713e Added tag hs24-b38 for changeset 795212ad5b1b ! .hgtags From krystal.mo at oracle.com Thu Mar 28 15:11:37 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 15:11:37 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros Message-ID: <5154C019.2000300@oracle.com> Hi all, Could I have a review for this small patch, please? Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 This patch improves the EC_TRACE and RC_TRACE* family of macros to be less error prone. They used to end with while(0) to make the macros statement-like, but a better way to do this is do {...} while(0). Testing with JPRT, will send an update email when it's done. P.S. I'm not sure where I should send this email for review, should it be hotspot-runtime or serviceability? Thanks, Kris From serguei.spitsyn at oracle.com Thu Mar 28 15:24:56 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Mar 2013 15:24:56 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C019.2000300@oracle.com> References: <5154C019.2000300@oracle.com> Message-ID: <5154C338.7030309@oracle.com> Hi Krystal, The fix is good. Thanks, Serguei On 3/28/13 3:11 PM, Krystal Mo wrote: > Hi all, > > Could I have a review for this small patch, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 > > This patch improves the EC_TRACE and RC_TRACE* family of macros to be > less error prone. > They used to end with while(0) to make the macros statement-like, but > a better way to do this is do {...} while(0). > > Testing with JPRT, will send an update email when it's done. > > P.S. I'm not sure where I should send this email for review, should it > be hotspot-runtime or serviceability? > > Thanks, > Kris From krystal.mo at oracle.com Thu Mar 28 15:26:14 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 15:26:14 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C338.7030309@oracle.com> References: <5154C019.2000300@oracle.com> <5154C338.7030309@oracle.com> Message-ID: <5154C386.7000300@oracle.com> Thank you, Serguei - Kris On 03/28/2013 03:24 PM, serguei.spitsyn at oracle.com wrote: > Hi Krystal, > > The fix is good. > > Thanks, > Serguei > > On 3/28/13 3:11 PM, Krystal Mo wrote: >> Hi all, >> >> Could I have a review for this small patch, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >> >> This patch improves the EC_TRACE and RC_TRACE* family of macros to be >> less error prone. >> They used to end with while(0) to make the macros statement-like, but >> a better way to do this is do {...} while(0). >> >> Testing with JPRT, will send an update email when it's done. >> >> P.S. I'm not sure where I should send this email for review, should >> it be hotspot-runtime or serviceability? >> >> Thanks, >> Kris > From daniel.daugherty at oracle.com Thu Mar 28 15:49:34 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Mar 2013 16:49:34 -0600 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C019.2000300@oracle.com> References: <5154C019.2000300@oracle.com> Message-ID: <5154C8FE.9000501@oracle.com> On 3/28/13 4:11 PM, Krystal Mo wrote: > Hi all, > > Could I have a review for this small patch, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 src/share/vm/prims/jvmtiEventController.cpp Thanks for reformatting the macro while you were in there. src/share/vm/prims/jvmtiRedefineClassesTrace.hpp I was wondering why you reordered the macros until I saw the updates to use RC_TRACE_ENABLED. Nicely done. Dan > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 > > This patch improves the EC_TRACE and RC_TRACE* family of macros to be > less error prone. > They used to end with while(0) to make the macros statement-like, but > a better way to do this is do {...} while(0). > > Testing with JPRT, will send an update email when it's done. > > P.S. I'm not sure where I should send this email for review, should it > be hotspot-runtime or serviceability? Serviceability would have been the default choice since this is JVM/TI code, but hotspot-dev is fine. You've already gotten a review from Serguei who in on Serviceability and now me (former Serviceability, now Runtime). Bases are covered, I think... Dan > > Thanks, > Kris From daniel.daugherty at oracle.com Thu Mar 28 15:51:57 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Mar 2013 16:51:57 -0600 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C8FE.9000501@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> Message-ID: <5154C98D.9000605@oracle.com> I forgot to say: thumbs up! Dan On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: > On 3/28/13 4:11 PM, Krystal Mo wrote: >> Hi all, >> >> Could I have a review for this small patch, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 > > src/share/vm/prims/jvmtiEventController.cpp > Thanks for reformatting the macro while you were in there. > > src/share/vm/prims/jvmtiRedefineClassesTrace.hpp > I was wondering why you reordered the macros until I saw the > updates to use RC_TRACE_ENABLED. Nicely done. > > Dan > > >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >> >> This patch improves the EC_TRACE and RC_TRACE* family of macros to be >> less error prone. >> They used to end with while(0) to make the macros statement-like, but >> a better way to do this is do {...} while(0). >> >> Testing with JPRT, will send an update email when it's done. >> >> P.S. I'm not sure where I should send this email for review, should >> it be hotspot-runtime or serviceability? > > Serviceability would have been the default choice since this > is JVM/TI code, but hotspot-dev is fine. You've already gotten > a review from Serguei who in on Serviceability and now me > (former Serviceability, now Runtime). Bases are covered, I think... > > Dan > >> >> Thanks, >> Kris > From krystal.mo at oracle.com Thu Mar 28 15:54:09 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 15:54:09 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C98D.9000605@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> Message-ID: <5154CA11.1040403@oracle.com> Thank you, Dan! Would you like it better if I reformat EC_TRACE to one statement on a line? - Kris On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: > I forgot to say: thumbs up! > > Dan > > > On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >> On 3/28/13 4:11 PM, Krystal Mo wrote: >>> Hi all, >>> >>> Could I have a review for this small patch, please? >>> >>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >> >> src/share/vm/prims/jvmtiEventController.cpp >> Thanks for reformatting the macro while you were in there. >> >> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >> I was wondering why you reordered the macros until I saw the >> updates to use RC_TRACE_ENABLED. Nicely done. >> >> Dan >> >> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>> >>> This patch improves the EC_TRACE and RC_TRACE* family of macros to >>> be less error prone. >>> They used to end with while(0) to make the macros statement-like, >>> but a better way to do this is do {...} while(0). >>> >>> Testing with JPRT, will send an update email when it's done. >>> >>> P.S. I'm not sure where I should send this email for review, should >>> it be hotspot-runtime or serviceability? >> >> Serviceability would have been the default choice since this >> is JVM/TI code, but hotspot-dev is fine. You've already gotten >> a review from Serguei who in on Serviceability and now me >> (former Serviceability, now Runtime). Bases are covered, I think... >> >> Dan >> >>> >>> Thanks, >>> Kris >> > From daniel.daugherty at oracle.com Thu Mar 28 15:55:16 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Mar 2013 16:55:16 -0600 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CA11.1040403@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> <5154CA11.1040403@oracle.com> Message-ID: <5154CA54.4070101@oracle.com> On 3/28/13 4:54 PM, Krystal Mo wrote: > Thank you, Dan! > Would you like it better if I reformat EC_TRACE to one statement on a > line? Please no! I like the new version much, much better... Dan > > - Kris > > On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: >> I forgot to say: thumbs up! >> >> Dan >> >> >> On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >>> On 3/28/13 4:11 PM, Krystal Mo wrote: >>>> Hi all, >>>> >>>> Could I have a review for this small patch, please? >>>> >>>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>> >>> src/share/vm/prims/jvmtiEventController.cpp >>> Thanks for reformatting the macro while you were in there. >>> >>> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >>> I was wondering why you reordered the macros until I saw the >>> updates to use RC_TRACE_ENABLED. Nicely done. >>> >>> Dan >>> >>> >>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>>> >>>> This patch improves the EC_TRACE and RC_TRACE* family of macros to >>>> be less error prone. >>>> They used to end with while(0) to make the macros statement-like, >>>> but a better way to do this is do {...} while(0). >>>> >>>> Testing with JPRT, will send an update email when it's done. >>>> >>>> P.S. I'm not sure where I should send this email for review, should >>>> it be hotspot-runtime or serviceability? >>> >>> Serviceability would have been the default choice since this >>> is JVM/TI code, but hotspot-dev is fine. You've already gotten >>> a review from Serguei who in on Serviceability and now me >>> (former Serviceability, now Runtime). Bases are covered, I think... >>> >>> Dan >>> >>>> >>>> Thanks, >>>> Kris >>> >> > From krystal.mo at oracle.com Thu Mar 28 15:59:34 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 15:59:34 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CA54.4070101@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> <5154CA11.1040403@oracle.com> <5154CA54.4070101@oracle.com> Message-ID: <5154CB56.5060307@oracle.com> No, I mean like the way RC_TRACE is: -#define EC_TRACE(out) if (JvmtiTrace::trace_event_controller()) { SafeResourceMark rm; tty->print_cr out; } while (0) +#define EC_TRACE(out) do { \ + if (JvmtiTrace::trace_event_controller()) { \ + SafeResourceMark rm; \ + tty->print_cr out; \ + } \ +} while (0) - Kris On 03/28/2013 03:55 PM, Daniel D. Daugherty wrote: > On 3/28/13 4:54 PM, Krystal Mo wrote: >> Thank you, Dan! >> Would you like it better if I reformat EC_TRACE to one statement on a >> line? > > Please no! I like the new version much, much better... > > Dan > > >> >> - Kris >> >> On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: >>> I forgot to say: thumbs up! >>> >>> Dan >>> >>> >>> On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >>>> On 3/28/13 4:11 PM, Krystal Mo wrote: >>>>> Hi all, >>>>> >>>>> Could I have a review for this small patch, please? >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>>> >>>> src/share/vm/prims/jvmtiEventController.cpp >>>> Thanks for reformatting the macro while you were in there. >>>> >>>> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >>>> I was wondering why you reordered the macros until I saw the >>>> updates to use RC_TRACE_ENABLED. Nicely done. >>>> >>>> Dan >>>> >>>> >>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>>>> >>>>> This patch improves the EC_TRACE and RC_TRACE* family of macros to >>>>> be less error prone. >>>>> They used to end with while(0) to make the macros statement-like, >>>>> but a better way to do this is do {...} while(0). >>>>> >>>>> Testing with JPRT, will send an update email when it's done. >>>>> >>>>> P.S. I'm not sure where I should send this email for review, >>>>> should it be hotspot-runtime or serviceability? >>>> >>>> Serviceability would have been the default choice since this >>>> is JVM/TI code, but hotspot-dev is fine. You've already gotten >>>> a review from Serguei who in on Serviceability and now me >>>> (former Serviceability, now Runtime). Bases are covered, I think... >>>> >>>> Dan >>>> >>>>> >>>>> Thanks, >>>>> Kris >>>> >>> >> > From daniel.daugherty at oracle.com Thu Mar 28 16:06:52 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Mar 2013 17:06:52 -0600 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CB56.5060307@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> <5154CA11.1040403@oracle.com> <5154CA54.4070101@oracle.com> <5154CB56.5060307@oracle.com> Message-ID: <5154CD0C.6000806@oracle.com> I'd be happy with either of your new versions. Sorry, I mis-read: reformat EC_TRACE to one statement on a line? as going back to the original everything on one line. I should have read it as: reformat EC_TRACE to one statement per line? Dan On 3/28/13 4:59 PM, Krystal Mo wrote: > No, I mean like the way RC_TRACE is: > > -#define EC_TRACE(out) if (JvmtiTrace::trace_event_controller()) { > SafeResourceMark rm; tty->print_cr out; } while (0) > +#define EC_TRACE(out) do { \ > + if (JvmtiTrace::trace_event_controller()) { \ > + SafeResourceMark rm; \ > + tty->print_cr out; \ > + } \ > +} while (0) > > - Kris > > On 03/28/2013 03:55 PM, Daniel D. Daugherty wrote: >> On 3/28/13 4:54 PM, Krystal Mo wrote: >>> Thank you, Dan! >>> Would you like it better if I reformat EC_TRACE to one statement on >>> a line? >> >> Please no! I like the new version much, much better... >> >> Dan >> >> >>> >>> - Kris >>> >>> On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: >>>> I forgot to say: thumbs up! >>>> >>>> Dan >>>> >>>> >>>> On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >>>>> On 3/28/13 4:11 PM, Krystal Mo wrote: >>>>>> Hi all, >>>>>> >>>>>> Could I have a review for this small patch, please? >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>>>> >>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>> Thanks for reformatting the macro while you were in there. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >>>>> I was wondering why you reordered the macros until I saw the >>>>> updates to use RC_TRACE_ENABLED. Nicely done. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>>>>> >>>>>> This patch improves the EC_TRACE and RC_TRACE* family of macros >>>>>> to be less error prone. >>>>>> They used to end with while(0) to make the macros statement-like, >>>>>> but a better way to do this is do {...} while(0). >>>>>> >>>>>> Testing with JPRT, will send an update email when it's done. >>>>>> >>>>>> P.S. I'm not sure where I should send this email for review, >>>>>> should it be hotspot-runtime or serviceability? >>>>> >>>>> Serviceability would have been the default choice since this >>>>> is JVM/TI code, but hotspot-dev is fine. You've already gotten >>>>> a review from Serguei who in on Serviceability and now me >>>>> (former Serviceability, now Runtime). Bases are covered, I think... >>>>> >>>>> Dan >>>>> >>>>>> >>>>>> Thanks, >>>>>> Kris >>>>> >>>> >>> >> > From mikael.vidstedt at oracle.com Thu Mar 28 16:12:15 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Mar 2013 16:12:15 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154C019.2000300@oracle.com> References: <5154C019.2000300@oracle.com> Message-ID: <5154CE4F.6000400@oracle.com> I'm curious: Are there any fundamental reasons for not turning these into real functions instead of using macros to avoid the problem all together? The only downside I can see is that the functions would to do a va_start/va_end and use the va_list version of print instead, but that doesn't seem all to bad? Cheers, Mikael On 2013-03-28 15:11, Krystal Mo wrote: > Hi all, > > Could I have a review for this small patch, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 > > This patch improves the EC_TRACE and RC_TRACE* family of macros to be > less error prone. > They used to end with while(0) to make the macros statement-like, but > a better way to do this is do {...} while(0). > > Testing with JPRT, will send an update email when it's done. > > P.S. I'm not sure where I should send this email for review, should it > be hotspot-runtime or serviceability? > > Thanks, > Kris From krystal.mo at oracle.com Thu Mar 28 16:22:42 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 16:22:42 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CE4F.6000400@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> Message-ID: <5154D0C2.7090308@oracle.com> Hi Mikael, I'd say it has to do with the way ResourceMark works. Dummy example: void foo(Symbol* sym) { RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource } ideally this should get expanded into: void foo(Symbol* sym) { if (RC_TRACE_ENABLED(some_level)) { ResourceMark rm; // note here tty->print("RedefineClasses-0x%x: ", level); tty->print("%s", sym->as_C_string()); // resource allocation in the same scope as the ResourceMark } } If RC_TRACE were made into a (inline) function, then the ResourceMark will have to be taken care of by the caller, like so: void foo(Symbol* sym) { ResourceMark rm; RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource } Otherwise we'd leak resource-allocated memory. This is the only reason I can think of for keeping it as a macro instead of turning it into a real function. - Kris On 03/28/2013 04:12 PM, Mikael Vidstedt wrote: > > I'm curious: Are there any fundamental reasons for not turning these > into real functions instead of using macros to avoid the problem all > together? The only downside I can see is that the functions would to > do a va_start/va_end and use the va_list version of print instead, but > that doesn't seem all to bad? > > Cheers, > Mikael > > On 2013-03-28 15:11, Krystal Mo wrote: >> Hi all, >> >> Could I have a review for this small patch, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >> >> This patch improves the EC_TRACE and RC_TRACE* family of macros to be >> less error prone. >> They used to end with while(0) to make the macros statement-like, but >> a better way to do this is do {...} while(0). >> >> Testing with JPRT, will send an update email when it's done. >> >> P.S. I'm not sure where I should send this email for review, should >> it be hotspot-runtime or serviceability? >> >> Thanks, >> Kris > From krystal.mo at oracle.com Thu Mar 28 16:23:08 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 28 Mar 2013 16:23:08 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CD0C.6000806@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> <5154CA11.1040403@oracle.com> <5154CA54.4070101@oracle.com> <5154CB56.5060307@oracle.com> <5154CD0C.6000806@oracle.com> Message-ID: <5154D0DC.3050300@oracle.com> I'd be happier with the newer one. Updated webrev in the same place. On 03/28/2013 04:06 PM, Daniel D. Daugherty wrote: > I'd be happy with either of your new versions. > > Sorry, I mis-read: > > reformat EC_TRACE to one statement on a line? > > as going back to the original everything on one line. > I should have read it as: > > reformat EC_TRACE to one statement per line? > I should have written it that way in the first place... Thanks, Kris > Dan > > > On 3/28/13 4:59 PM, Krystal Mo wrote: >> No, I mean like the way RC_TRACE is: >> >> -#define EC_TRACE(out) if (JvmtiTrace::trace_event_controller()) { >> SafeResourceMark rm; tty->print_cr out; } while (0) >> +#define EC_TRACE(out) do { \ >> + if (JvmtiTrace::trace_event_controller()) { \ >> + SafeResourceMark rm; \ >> + tty->print_cr out; \ >> + } \ >> +} while (0) >> >> - Kris >> >> On 03/28/2013 03:55 PM, Daniel D. Daugherty wrote: >>> On 3/28/13 4:54 PM, Krystal Mo wrote: >>>> Thank you, Dan! >>>> Would you like it better if I reformat EC_TRACE to one statement on >>>> a line? >>> >>> Please no! I like the new version much, much better... >>> >>> Dan >>> >>> >>>> >>>> - Kris >>>> >>>> On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: >>>>> I forgot to say: thumbs up! >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >>>>>> On 3/28/13 4:11 PM, Krystal Mo wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a review for this small patch, please? >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>>>>> >>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>> Thanks for reformatting the macro while you were in there. >>>>>> >>>>>> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >>>>>> I was wondering why you reordered the macros until I saw the >>>>>> updates to use RC_TRACE_ENABLED. Nicely done. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>>>>>> >>>>>>> This patch improves the EC_TRACE and RC_TRACE* family of macros >>>>>>> to be less error prone. >>>>>>> They used to end with while(0) to make the macros >>>>>>> statement-like, but a better way to do this is do {...} while(0). >>>>>>> >>>>>>> Testing with JPRT, will send an update email when it's done. >>>>>>> >>>>>>> P.S. I'm not sure where I should send this email for review, >>>>>>> should it be hotspot-runtime or serviceability? >>>>>> >>>>>> Serviceability would have been the default choice since this >>>>>> is JVM/TI code, but hotspot-dev is fine. You've already gotten >>>>>> a review from Serguei who in on Serviceability and now me >>>>>> (former Serviceability, now Runtime). Bases are covered, I think... >>>>>> >>>>>> Dan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Kris >>>>>> >>>>> >>>> >>> >> > From mikael.vidstedt at oracle.com Thu Mar 28 16:24:23 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Mar 2013 16:24:23 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154D0C2.7090308@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> Message-ID: <5154D127.5080803@oracle.com> Good point, thanks for clarifying.. /Mikael - macro hater On 3/28/2013 4:22 PM, Krystal Mo wrote: > Hi Mikael, > > I'd say it has to do with the way ResourceMark works. > > Dummy example: > > void foo(Symbol* sym) { > RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource > } > > ideally this should get expanded into: > > void foo(Symbol* sym) { > if (RC_TRACE_ENABLED(some_level)) { > ResourceMark rm; // note here > tty->print("RedefineClasses-0x%x: ", level); > tty->print("%s", sym->as_C_string()); // resource allocation in > the same scope as the ResourceMark > } > } > > If RC_TRACE were made into a (inline) function, then the ResourceMark > will have to be taken care of by the caller, like so: > > void foo(Symbol* sym) { > ResourceMark rm; > RC_TRACE(("%s", sym->as_C_string())); // as_C_string allocates resource > } > > Otherwise we'd leak resource-allocated memory. This is the only reason > I can think of for keeping it as a macro instead of turning it into a > real function. > > - Kris > > On 03/28/2013 04:12 PM, Mikael Vidstedt wrote: >> >> I'm curious: Are there any fundamental reasons for not turning these >> into real functions instead of using macros to avoid the problem all >> together? The only downside I can see is that the functions would to >> do a va_start/va_end and use the va_list version of print instead, >> but that doesn't seem all to bad? >> >> Cheers, >> Mikael >> >> On 2013-03-28 15:11, Krystal Mo wrote: >>> Hi all, >>> >>> Could I have a review for this small patch, please? >>> >>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>> >>> This patch improves the EC_TRACE and RC_TRACE* family of macros to >>> be less error prone. >>> They used to end with while(0) to make the macros statement-like, >>> but a better way to do this is do {...} while(0). >>> >>> Testing with JPRT, will send an update email when it's done. >>> >>> P.S. I'm not sure where I should send this email for review, should >>> it be hotspot-runtime or serviceability? >>> >>> Thanks, >>> Kris >> > From serguei.spitsyn at oracle.com Thu Mar 28 16:25:11 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Mar 2013 16:25:11 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154CA54.4070101@oracle.com> References: <5154C019.2000300@oracle.com> <5154C8FE.9000501@oracle.com> <5154C98D.9000605@oracle.com> <5154CA11.1040403@oracle.com> <5154CA54.4070101@oracle.com> Message-ID: <5154D157.2030103@oracle.com> On 3/28/13 3:55 PM, Daniel D. Daugherty wrote: > On 3/28/13 4:54 PM, Krystal Mo wrote: >> Thank you, Dan! >> Would you like it better if I reformat EC_TRACE to one statement on a >> line? > > Please no! I like the new version much, much better... +1 for this. Thanks, Serguei > > Dan > > >> >> - Kris >> >> On 03/28/2013 03:51 PM, Daniel D. Daugherty wrote: >>> I forgot to say: thumbs up! >>> >>> Dan >>> >>> >>> On 3/28/13 4:49 PM, Daniel D. Daugherty wrote: >>>> On 3/28/13 4:11 PM, Krystal Mo wrote: >>>>> Hi all, >>>>> >>>>> Could I have a review for this small patch, please? >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~kmo/8011009/webrev.00 >>>> >>>> src/share/vm/prims/jvmtiEventController.cpp >>>> Thanks for reformatting the macro while you were in there. >>>> >>>> src/share/vm/prims/jvmtiRedefineClassesTrace.hpp >>>> I was wondering why you reordered the macros until I saw the >>>> updates to use RC_TRACE_ENABLED. Nicely done. >>>> >>>> Dan >>>> >>>> >>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011009 >>>>> >>>>> This patch improves the EC_TRACE and RC_TRACE* family of macros to >>>>> be less error prone. >>>>> They used to end with while(0) to make the macros statement-like, >>>>> but a better way to do this is do {...} while(0). >>>>> >>>>> Testing with JPRT, will send an update email when it's done. >>>>> >>>>> P.S. I'm not sure where I should send this email for review, >>>>> should it be hotspot-runtime or serviceability? >>>> >>>> Serviceability would have been the default choice since this >>>> is JVM/TI code, but hotspot-dev is fine. You've already gotten >>>> a review from Serguei who in on Serviceability and now me >>>> (former Serviceability, now Runtime). Bases are covered, I think... >>>> >>>> Dan >>>> >>>>> >>>>> Thanks, >>>>> Kris >>>> >>> >> > From john.r.rose at oracle.com Thu Mar 28 16:55:27 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Mar 2013 16:55:27 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5154D0C2.7090308@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> Message-ID: <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> On Mar 28, 2013, at 4:22 PM, Krystal Mo wrote: > I'd say it has to do with the way ResourceMark works. This is a common feature with all sorts of conditional coprocessing facilities. The pattern is: x = some_value; if (logging_is_enabled) { x' = derive_interesting_details_for_logging(x); print_to_logger(x'); } One would like to capture it in a subroutine: x = some_value; maybe_log(derive_interesting_details_for_logging(x)); But this transfers the expense of digging out the "details" (or the formatted detail string) outside of the guard, adding an expense even when the logging is disabled. Assertions can also be thought of as a sort of conditional processing. Java works around the expense of computing assertion parameters by making the whole thing a special language feature under a keyword. In JDK 8 with lambdas, there will be new options for conditional execution of expressions: x = some_value; maybe_log(()->derive_interesting_details_for_logging(x)); In C, we get to use macros for this sort of thing. ? John From vitalyd at gmail.com Thu Mar 28 17:01:53 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 28 Mar 2013 20:01:53 -0400 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> Message-ID: John, with lambdas that capture variables there's still the issue of allocating the holder class isn't there? So you remove the overhead of deriving the message but you still get GC churn (unless JIT inlines and escape analyzes out the alloc, but I don't think it's very reliable). Sent from my phone On Mar 28, 2013 7:56 PM, "John Rose" wrote: > On Mar 28, 2013, at 4:22 PM, Krystal Mo wrote: > > > I'd say it has to do with the way ResourceMark works. > > This is a common feature with all sorts of conditional coprocessing > facilities. The pattern is: > > x = some_value; > if (logging_is_enabled) { > x' = derive_interesting_details_for_logging(x); > print_to_logger(x'); > } > > One would like to capture it in a subroutine: > > x = some_value; > maybe_log(derive_interesting_details_for_logging(x)); > > But this transfers the expense of digging out the "details" (or the > formatted detail string) outside of the guard, adding an expense even when > the logging is disabled. > > Assertions can also be thought of as a sort of conditional processing. > Java works around the expense of computing assertion parameters by making > the whole thing a special language feature under a keyword. > > In JDK 8 with lambdas, there will be new options for conditional execution > of expressions: > > x = some_value; > maybe_log(()->derive_interesting_details_for_logging(x)); > > In C, we get to use macros for this sort of thing. > > ? John From john.r.rose at oracle.com Thu Mar 28 17:19:12 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 28 Mar 2013 17:19:12 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> Message-ID: <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> On Mar 28, 2013, at 5:01 PM, Vitaly Davidovich wrote: > John, with lambdas that capture variables there's still the issue of allocating the holder class isn't there? So you remove the overhead of deriving the message but you still get GC churn (unless JIT inlines and escape analyzes out the alloc, but I don't think it's very reliable). The "holder object" is stateless and can be adjusted by the runtime system, so we can play tricks like you point out. It is a prime candidate for escape analysis, for example. The JVM can delay allocation of certain objects by putting a "recipe" for the desired object in the debug info, and only executing it after an uncommon trap. For making such transforms absolutely reliable we need macros or AOT or "assert 2.0" or something like that. But I hope users can get most of what they want from good-enough optimization of lambda. ? John From forax at univ-mlv.fr Thu Mar 28 17:26:31 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 Mar 2013 01:26:31 +0100 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> Message-ID: <5154DFB7.4040209@univ-mlv.fr> On 03/29/2013 01:19 AM, John Rose wrote: > On Mar 28, 2013, at 5:01 PM, Vitaly Davidovich wrote: > >> John, with lambdas that capture variables there's still the issue of allocating the holder class isn't there? So you remove the overhead of deriving the message but you still get GC churn (unless JIT inlines and escape analyzes out the alloc, but I don't think it's very reliable). > The "holder object" is stateless and can be adjusted by the runtime system, so we can play tricks like you point out. It is a prime candidate for escape analysis, for example. The JVM can delay allocation of certain objects by putting a "recipe" for the desired object in the debug info, and only executing it after an uncommon trap. That means you still need to keep the register that contains 'x' longer than you should (if x is not used after the call to maybe_log). > > For making such transforms absolutely reliable we need macros or AOT or "assert 2.0" or something like that. But I hope users can get most of what they want from good-enough optimization of lambda. or invokedynamic in Java (correct me if I'm wrong but there is no uncommon trap if the BSM returns a no-op). > > ? John R?mi From vitalyd at gmail.com Thu Mar 28 17:49:47 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 28 Mar 2013 20:49:47 -0400 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> Message-ID: How's it stateless if it's capturing variables in the caller? Or do you mean you encode the recipe somewhere and holder just cooks it up if needed? So uncommon trap may start deoptimizing repeatedly and at some point kill the optimization entirely - benefits of recipe go away here? Anyway, what I find missing in java is "watered down" macros/compiler directives ala C# - it hits the common cases well without allowing abuse. That's really what I'd want - in a lot of these cases I don't want some code to appear in the bytecode at all, nevermind being optimized by JIT. All we have in java to emulate this is static final boolean inside compilation unit, which is a hack and requires source change to toggle. :) Thanks Sent from my phone On Mar 28, 2013 8:19 PM, "John Rose" wrote: > On Mar 28, 2013, at 5:01 PM, Vitaly Davidovich wrote: > > John, with lambdas that capture variables there's still the issue of > allocating the holder class isn't there? So you remove the overhead of > deriving the message but you still get GC churn (unless JIT inlines and > escape analyzes out the alloc, but I don't think it's very reliable). > > > The "holder object" is stateless and can be adjusted by the runtime > system, so we can play tricks like you point out. It is a prime candidate > for escape analysis, for example. The JVM can delay allocation of certain > objects by putting a "recipe" for the desired object in the debug info, and > only executing it after an uncommon trap. > > For making such transforms absolutely reliable we need macros or AOT or > "assert 2.0" or something like that. But I hope users can get most of what > they want from good-enough optimization of lambda. > > ? John > From forax at univ-mlv.fr Thu Mar 28 17:55:42 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 Mar 2013 01:55:42 +0100 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> <5AF6407C-06F2-419A-BBAD-D65941471BF9@oracle.com> Message-ID: <5154E68E.8010404@univ-mlv.fr> On 03/29/2013 01:49 AM, Vitaly Davidovich wrote: > How's it stateless if it's capturing variables in the caller? Or do you > mean you encode the recipe somewhere and holder just cooks it up if needed? > So uncommon trap may start deoptimizing repeatedly and at some point kill > the optimization entirely - benefits of recipe go away here? I think that the idea is to make the deopt a little smarter to instead of just transferng registers value to interpreter data structures, you add a pass that is able to create lambda proxy (I don't see how to make that generics for any object). IMO, it's better to do the create the lambda proxy just before the uncommon trap exactly like partial escape analysis does. > > Anyway, what I find missing in java is "watered down" macros/compiler > directives ala C# - it hits the common cases well without allowing abuse. > That's really what I'd want - in a lot of these cases I don't want some > code to appear in the bytecode at all, nevermind being optimized by JIT. > All we have in java to emulate this is static final boolean inside > compilation unit, which is a hack and requires source change to toggle. :) > > Thanks cheers, R?mi > > Sent from my phone > On Mar 28, 2013 8:19 PM, "John Rose" wrote: > >> On Mar 28, 2013, at 5:01 PM, Vitaly Davidovich wrote: >> >> John, with lambdas that capture variables there's still the issue of >> allocating the holder class isn't there? So you remove the overhead of >> deriving the message but you still get GC churn (unless JIT inlines and >> escape analyzes out the alloc, but I don't think it's very reliable). >> >> >> The "holder object" is stateless and can be adjusted by the runtime >> system, so we can play tricks like you point out. It is a prime candidate >> for escape analysis, for example. The JVM can delay allocation of certain >> objects by putting a "recipe" for the desired object in the debug info, and >> only executing it after an uncommon trap. >> >> For making such transforms absolutely reliable we need macros or AOT or >> "assert 2.0" or something like that. But I hope users can get most of what >> they want from good-enough optimization of lambda. >> >> ? John >> From gary.collins at oracle.com Thu Mar 28 18:00:08 2013 From: gary.collins at oracle.com (gary.collins at oracle.com) Date: Fri, 29 Mar 2013 01:00:08 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130329010018.BAE7748484@hg.openjdk.java.net> Changeset: 728b89404e34 Author: jprovino Date: 2013-03-21 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/728b89404e34 8009904: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm Summary: jvmtiClassFileReconstituter.cpp needs to be added to the list of files to exclude when JVMTI is excluded from the jvm Reviewed-by: dholmes, sspitsyn ! make/excludeSrc.make Changeset: 7ca101eef24a Author: jprovino Date: 2013-03-23 14:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7ca101eef24a Merge Changeset: 04d6d4322c6a Author: collins Date: 2013-03-27 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04d6d4322c6a 8009152: A number of jtreg tests need review/improvement Summary: Added a new test_env.txt file to capture common shell variable. Added concept of COMPILEJAVA for use when TESTJAVA is a JRE. If COMPILEJAVA not set then TESTJAVA will be the default with assumption it is a JDK. Reviewed-by: kvn, brutisso, coleenp ! test/compiler/5091921/Test6890943.sh ! test/compiler/5091921/Test7005594.sh ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158804/Test7158804.sh ! test/runtime/7162488/Test7162488.sh + test/test_env.sh Changeset: d1897e7e0488 Author: collins Date: 2013-03-28 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d1897e7e0488 Merge ! test/runtime/6878713/Test6878713.sh From alejandro.murillo at oracle.com Thu Mar 28 18:06:32 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 29 Mar 2013 01:06:32 +0000 Subject: hg: hsx/hsx24/hotspot: 8011021: new hotspot build - hs24-b39 Message-ID: <20130329010637.283A148485@hg.openjdk.java.net> Changeset: 7c8d60d568ba Author: amurillo Date: 2013-03-28 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7c8d60d568ba 8011021: new hotspot build - hs24-b39 Reviewed-by: jcoomes ! make/hotspot_version From john.coomes at oracle.com Thu Mar 28 20:32:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:32:14 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b83 for changeset a1dcc0d83da1 Message-ID: <20130329033219.15CF44848F@hg.openjdk.java.net> Changeset: 54c29eb352e7 Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/54c29eb352e7 Added tag jdk8-b83 for changeset a1dcc0d83da1 ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:31:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:31:51 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b83 for changeset a45bb25a67c7 Message-ID: <20130329033154.D07BD4848D@hg.openjdk.java.net> Changeset: 14f1babaf548 Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/14f1babaf548 Added tag jdk8-b83 for changeset a45bb25a67c7 ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:32:27 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:32:27 +0000 Subject: hg: hsx/hotspot-main/jdk: 3 new changesets Message-ID: <20130329033344.BD2E348490@hg.openjdk.java.net> Changeset: 6782f2c46bca Author: wetmore Date: 2013-03-21 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6782f2c46bca 8009517: new code changes causing errors in old build (-Werror) environment Reviewed-by: mduigou ! make/com/sun/org/apache/xml/Makefile ! make/javax/others/Makefile Changeset: ac519af51769 Author: dcherepanov Date: 2013-03-27 08:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac519af51769 Merge Changeset: 8cc500af2454 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cc500af2454 Added tag jdk8-b83 for changeset ac519af51769 ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:31:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:31:47 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b83 for changeset 466685ba01bf Message-ID: <20130329033147.876674848C@hg.openjdk.java.net> Changeset: d409b4cdb74f Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d409b4cdb74f Added tag jdk8-b83 for changeset 466685ba01bf ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:31:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:31:59 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b83 for changeset a46d69a1a8ec Message-ID: <20130329033209.050A84848E@hg.openjdk.java.net> Changeset: f5f40094ffcc Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f5f40094ffcc Added tag jdk8-b83 for changeset a46d69a1a8ec ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:35:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:35:14 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b83 for changeset 22ba3f92d4ae Message-ID: <20130329033522.EEC7D48491@hg.openjdk.java.net> Changeset: 35cef52b0023 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/35cef52b0023 Added tag jdk8-b83 for changeset 22ba3f92d4ae ! .hgtags From john.coomes at oracle.com Thu Mar 28 20:35:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:35:28 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b83 for changeset 053d7c55dc82 Message-ID: <20130329033530.522A148492@hg.openjdk.java.net> Changeset: fbbdef940138 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fbbdef940138 Added tag jdk8-b83 for changeset 053d7c55dc82 ! .hgtags From alejandro.murillo at oracle.com Thu Mar 28 22:24:00 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 29 Mar 2013 05:24:00 +0000 Subject: hg: hsx/hsx25/hotspot: 35 new changesets Message-ID: <20130329052510.BC868484B1@hg.openjdk.java.net> Changeset: e614fc564ded Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e614fc564ded Added tag jdk8-b83 for changeset 1c8db54ee9f3 ! .hgtags Changeset: 59a41e1357ab Author: amurillo Date: 2013-03-23 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59a41e1357ab 8010498: new hotspot build - hs25-b25 Reviewed-by: jcoomes ! make/hotspot_version Changeset: eca90b8a06eb Author: rdurbin Date: 2013-03-19 11:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eca90b8a06eb 7030610: runtime/6878713/Test6878713.sh fails Error. failed to clean up files after test 7123945: runtime/6878713/Test6878713.sh require about 2G of native memory, swaps and times out Summary: Add new diagnostic option -XX:MallocMaxTestWords=NNN and fix Test6878713.sh. Reviewed-by: dcubed, coleenp, dholmes, iklam ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! test/runtime/6878713/Test6878713.sh Changeset: a649f6511c04 Author: ctornqvi Date: 2013-03-20 08:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a649f6511c04 8010084: Race in runtime/NMT/BaselineWithParameter.java Summary: Added a waitFor() on the process Reviewed-by: mgerdin, sla, zgu ! test/runtime/NMT/BaselineWithParameter.java Changeset: 91bf0bdae37b Author: coleenp Date: 2013-03-20 08:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91bf0bdae37b 8008217: CDS: Class data sharing limits the malloc heap on Solaris Summary: In 64bit VM move CDS archive address to 32G on all platforms using new flag SharedBaseAddress. In 32bit VM set CDS archive address to 3Gb on Linux and let other OSs pick the address. Reviewed-by: kvn, dcubed, zgu, hseigel ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2c7663baeb67 Author: acorn Date: 2013-03-20 11:43 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c7663baeb67 8010017: lambda: reflection get(Declared)Methods support for default methods. Summary: Don't expose vm generated overpass (bridges to default methods). Reviewed-by: dholmes, fparain ! src/share/vm/prims/jvm.cpp Changeset: 79259e97a072 Author: acorn Date: 2013-03-20 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79259e97a072 Merge Changeset: 1feda2e9f044 Author: ctornqvi Date: 2013-03-20 20:40 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1feda2e9f044 8007982: some runtime/CommandLine/ tests fail on 32-bit platforms Summary: Changed tests to use platform independent flags Reviewed-by: collins, hseigel, zgu ! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java ! test/runtime/CommandLine/FlagWithInvalidValue.java ! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java Changeset: 81d1b58c078f Author: rdurbin Date: 2013-03-20 20:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/81d1b58c078f 8010396: checking MallocMaxTestWords in testMalloc() function is redundant Summary: Remove redundant checks in testMalloc and add assert. Reviewed-by: dcubed, coleenp, dholmes ! src/share/vm/runtime/os.cpp Changeset: e7081eb7e786 Author: dcubed Date: 2013-03-20 20:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7081eb7e786 Merge Changeset: 06db4c0afbf3 Author: zgu Date: 2013-03-20 09:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/06db4c0afbf3 8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT 8009777: NMT: add new NMT dcmd to control auto shutdown option Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation Reviewed-by: dcubed, coleenp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 0ac03fef364f Author: zgu Date: 2013-03-21 06:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0ac03fef364f Merge ! src/share/vm/runtime/globals.hpp Changeset: 14509df4cd63 Author: iklam Date: 2013-03-21 20:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/14509df4cd63 8010389: After fix for 7107135 a failed dlopen() call results in a VM crash Summary: Call dlerror() in VM thread as necessary. Reviewed-by: coleenp, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp + test/runtime/8010389/VMThreadDlopen.java Changeset: 6574f999e0cf Author: dcubed Date: 2013-03-23 22:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6574f999e0cf Merge ! src/share/vm/memory/metaspace.cpp Changeset: c342fbdf8a70 Author: ctornqvi Date: 2013-03-24 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c342fbdf8a70 8008454: test/runtime/NMT/PrintNMTStatistics is broken Summary: Added @run tag so that it actually runs the test, also fixed broken command line and incorrect parsing. Also reviewed by gerard.ziemski at oracle.com Reviewed-by: mgerdin, zgu ! test/runtime/NMT/PrintNMTStatistics.java Changeset: 9c8e53c7bed0 Author: ctornqvi Date: 2013-03-24 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9c8e53c7bed0 Merge - make/test/Queens.java Changeset: 729be16a470b Author: hseigel Date: 2013-03-25 08:37 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/729be16a470b 8010667: Non-zero padding is not allowed in splitverifier for tableswitch/lookupswitch instructions. Summary: Don't check the padding bits if class file version is >= 51. Reviewed-by: kvn, dholmes, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b8deb3205b51 Author: bharadwaj Date: 2013-03-25 09:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b8deb3205b51 8009552: test/vm/verifier/TestStaticIF.java failing with hs25.0-b Summary: Remove support for verification of class files with version 52 and above from type inference verifier. Reviewed-by: acorn, hseigel ! src/share/vm/classfile/verifier.cpp - test/runtime/8007736/TestStaticIF.java Changeset: 1916ca1dec2f Author: rbackman Date: 2013-03-26 15:00 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1916ca1dec2f 8009382: Add JVM_Get{Field|Method}TypeAnnotations Reviewed-by: dcubed, rbackman Contributed-by: Joel Borggren-Franck ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 36376b540a98 Author: hseigel Date: 2013-03-26 09:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/36376b540a98 8009595: The UseSplitVerifier option needs to be deprecated. Summary: Put UseSplitVerifier option on the deprecated list. Reviewed-by: dcubed, kmo, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a8016373a893 Author: hseigel Date: 2013-03-26 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a8016373a893 Merge Changeset: 6b748c9e1845 Author: zgu Date: 2013-03-26 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b748c9e1845 8010651: create.bat still builds the kernel Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows Reviewed-by: coleenp, sla ! make/windows/build.make ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/product.make ! make/windows/makefiles/vm.make - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java Changeset: 85192022ba8c Author: zgu Date: 2013-03-26 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85192022ba8c Merge - test/runtime/8007736/TestStaticIF.java Changeset: 23f2d309e855 Author: zgu Date: 2013-03-26 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/23f2d309e855 Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw Changeset: 7f16d1812865 Author: tamao Date: 2013-03-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7f16d1812865 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Summary: Remove the related assertions becasue they do not hold here. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp Changeset: dbd5837b342f Author: ehelin Date: 2013-03-22 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dbd5837b342f 8000754: NPG: Implement a MemoryPool MXBean for Metaspace Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: 338b3a9e29b5 Author: stefank Date: 2013-03-25 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/338b3a9e29b5 Merge ! src/share/vm/services/memoryService.cpp Changeset: 42e370795a39 Author: ehelin Date: 2013-03-27 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/42e370795a39 8010818: NPG: Remove metaspace memory pools Reviewed-by: mgerdin, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp - test/gc/metaspace/TestMetaspaceMemoryPools.java Changeset: aeb22fdaa14c Author: brutisso Date: 2013-03-28 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aeb22fdaa14c Merge ! src/share/vm/runtime/arguments.cpp Changeset: 728b89404e34 Author: jprovino Date: 2013-03-21 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/728b89404e34 8009904: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm Summary: jvmtiClassFileReconstituter.cpp needs to be added to the list of files to exclude when JVMTI is excluded from the jvm Reviewed-by: dholmes, sspitsyn ! make/excludeSrc.make Changeset: 7ca101eef24a Author: jprovino Date: 2013-03-23 14:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ca101eef24a Merge Changeset: 04d6d4322c6a Author: collins Date: 2013-03-27 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04d6d4322c6a 8009152: A number of jtreg tests need review/improvement Summary: Added a new test_env.txt file to capture common shell variable. Added concept of COMPILEJAVA for use when TESTJAVA is a JRE. If COMPILEJAVA not set then TESTJAVA will be the default with assumption it is a JDK. Reviewed-by: kvn, brutisso, coleenp ! test/compiler/5091921/Test6890943.sh ! test/compiler/5091921/Test7005594.sh ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158804/Test7158804.sh ! test/runtime/7162488/Test7162488.sh + test/test_env.sh Changeset: d1897e7e0488 Author: collins Date: 2013-03-28 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d1897e7e0488 Merge ! test/runtime/6878713/Test6878713.sh Changeset: 8d0f263a370c Author: amurillo Date: 2013-03-28 19:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d0f263a370c Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw - test/runtime/8007736/TestStaticIF.java Changeset: af788b85010e Author: amurillo Date: 2013-03-28 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/af788b85010e Added tag hs25-b25 for changeset 8d0f263a370c ! .hgtags From alejandro.murillo at oracle.com Fri Mar 29 02:13:24 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 29 Mar 2013 09:13:24 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130329091339.A0FD7484B6@hg.openjdk.java.net> Changeset: e614fc564ded Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e614fc564ded Added tag jdk8-b83 for changeset 1c8db54ee9f3 ! .hgtags Changeset: 8d0f263a370c Author: amurillo Date: 2013-03-28 19:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d0f263a370c Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw - test/runtime/8007736/TestStaticIF.java Changeset: af788b85010e Author: amurillo Date: 2013-03-28 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/af788b85010e Added tag hs25-b25 for changeset 8d0f263a370c ! .hgtags Changeset: d26674db4d91 Author: amurillo Date: 2013-03-28 19:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d26674db4d91 8011022: new hotspot build - hs25-b26 Reviewed-by: jcoomes ! make/hotspot_version From krystal.mo at oracle.com Fri Mar 29 04:12:07 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 29 Mar 2013 04:12:07 -0700 Subject: Request for review (S): JDK-8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros In-Reply-To: <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> References: <5154C019.2000300@oracle.com> <5154CE4F.6000400@oracle.com> <5154D0C2.7090308@oracle.com> <0271AA7B-C6BB-4AD1-B0AC-C00DDFAB6043@oracle.com> Message-ID: <51557707.40308@oracle.com> Thanks John, you're the man! Yes, in general the reason is about variable capturing and composing code. If we can use C++11 lambdas ew might get rid of some of these macros and turn them into functions...well I'm just saying. - Kris On 03/28/2013 04:55 PM, John Rose wrote: > On Mar 28, 2013, at 4:22 PM, Krystal Mo > wrote: > >> I'd say it has to do with the way ResourceMark works. > > This is a common feature with all sorts of conditional coprocessing > facilities. The pattern is: > > x = some_value; > if (logging_is_enabled) { > x' = derive_interesting_details_for_logging(x); > print_to_logger(x'); > } > > One would like to capture it in a subroutine: > > x = some_value; > maybe_log(derive_interesting_details_for_logging(x)); > > But this transfers the expense of digging out the "details" (or the > formatted detail string) outside of the guard, adding an expense even > when the logging is disabled. > > Assertions can also be thought of as a sort of conditional processing. > Java works around the expense of computing assertion parameters by > making the whole thing a special language feature under a keyword. > > In JDK 8 with lambdas, there will be new options for conditional > execution of expressions: > > x = some_value; > maybe_log(()->derive_interesting_details_for_logging(x)); > > In C, we get to use macros for this sort of thing. > > ? John From zhengyu.gu at oracle.com Fri Mar 29 09:53:39 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 29 Mar 2013 16:53:39 +0000 Subject: hg: hsx/hsx24/hotspot: 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Message-ID: <20130329165344.13603484C1@hg.openjdk.java.net> Changeset: 19c1e132e9ee Author: iklam Date: 2013-03-28 19:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/19c1e132e9ee 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c + test/runtime/8010389/VMThreadDlopen.java From zhengyu.gu at oracle.com Fri Mar 29 13:19:19 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 29 Mar 2013 20:19:19 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130329201929.72E07484C5@hg.openjdk.java.net> Changeset: aea9eb48dafd Author: zgu Date: 2013-03-29 10:02 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aea9eb48dafd 8010651: create.bat still builds the kernel Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows Reviewed-by: coleenp, sla ! make/windows/build.make ! make/windows/create.bat ! make/windows/makefiles/compile.make ! make/windows/makefiles/product.make - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java Changeset: cd85890e1926 Author: zgu Date: 2013-03-29 07:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cd85890e1926 Merge Changeset: ad6f90552a1c Author: zgu Date: 2013-03-29 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ad6f90552a1c Merge - make/windows/projectfiles/kernel/Makefile - make/windows/projectfiles/kernel/vm.def - make/windows/projectfiles/kernel/vm.dsw From vladimir.voskresensky at oracle.com Sat Mar 30 04:03:51 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky) Date: Sat, 30 Mar 2013 15:03:51 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51531883.7070903@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> Message-ID: <5156C697.8060003@oracle.com> Jesper, It looks good and works for me on Linux_64. Some comments for others: before running IDE specify IDE_JAVAPATH env variable if want to navigate into some java/include files (value is the same as previously was known as ALT_BOOTDIR): #export IDE_JAVAPATH=/opt/jdk/latest7 after opening project, make sure you are switched to Linux configuration Thanks! Vladimir. On 03/27/2013 08:04 PM, Jesper Wilhelmsson wrote: > Hi, > > A new webrev is now available. The issues reported from the first > review should be fixed and the project now contains configurations for > both Linux_64 and Mac_64. > > To select configuration there is a dropdown menu next to the build > button. > > http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ > > Thanks, > /Jesper > > > Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several >> areas. >> >> I would like to add Solaris Studio / NetBeans project files for the >> entire >> OpenJDK project. To clarify: One project that contains the entire >> OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire >> OpenJDK is fairly >> fast and even though I personally mostly work in the HotSpot tree, I >> tend to >> always clone and build the entire JDK forest. I find this to have >> several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and >> Solaris >> configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I >> think a >> change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper