Re: custom extension for make/SourceRevision.gmk

Done: https://bugs.openjdk.java.net/browse/JDK-8210008 > On Aug 23, 2018, at 4:56 PM, Erik Joelsson wrote: >

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 9:17 PM, Christian Thalinger > wrote: > > > >> On Jul 19, 2018, at 2:31 PM, Erik Joelsson > <mailto:erik.joels...@oracle.com>> wrote: >> >> I can do that. Do you have a bug? >> > No. Sorry, was on vacation

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 2:31 PM, Erik Joelsson wrote: > > I can do that. Do you have a bug? > No. > /Erik > > On 2018-07-19 10:57, Christian Thalinger wrote: >> >> >> On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson > <mailto:erik.joels...

Re: custom extension for make/SourceRevision.gmk

On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson wrote: > This looks good to me, but will need coordination when pushed as I said > earlier. > Do you want to push it so it’s easier? /Erik > > On 2018-07-19 10:04, Christian Thalinger wrote: > > > > On Jul 19, 2018,

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:57 PM, Erik Joelsson wrote: > > > > On 2018-07-19 09:54, Christian Thalinger wrote: >> >> >>> On Jul 19, 2018, at 12:44 PM, Erik Joelsson >> <mailto:erik.joels...@oracle.com>> wrote: >>&

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:44 PM, Erik Joelsson wrote: > > > On 2018-07-19 09:16, Christian Thalinger wrote: >> >> >> Well, the issue is this: >> >> exploded-image: exploded-image-base release-file >> >> release-file: creat

Re: custom extension for make/SourceRevision.gmk

other files. > > /Erik > > > On 2018-07-19 09:44, Erik Joelsson wrote: >> >> On 2018-07-19 09:16, Christian Thalinger wrote: >>> >>> >>> Well, the issue is this: >>> >>> exploded-image: exploded-image-base releas

Re: custom extension for make/SourceRevision.gmk

> On Jul 19, 2018, at 12:08 PM, Erik Joelsson wrote: > > Hello, > On 2018-07-19 07:43, Christian Thalinger wrote: >> >> >>> On Jul 18, 2018, at 3:28 PM, Christian Thalinger >> <mailto:cthalin...@twitter.com>> wrote: >>>

Re: custom extension for make/SourceRevision.gmk

> On Jul 18, 2018, at 3:28 PM, Christian Thalinger > wrote: > > > >> On Jul 18, 2018, at 1:46 PM, Erik Joelsson wrote: >> >> Hello Christian, >> >> Sometimes we need hooks both close to the beginning and close to the end of >>

Re: custom extension for make/SourceRevision.gmk

ate a > SourceBundle-post.gmk and clear the TARGETS variable from any targets you > don't want to run from the open file. Does that sound ok? Yes, that would be great. In JDK 11, please :-) > > /Erik > > > On 2018-07-18 10:31, Christian Thalinger wrote: >> Here at Twitte

custom extension for make/SourceRevision.gmk

Here at Twitter our OpenJDK clone lives in a GIT repository and we would like to use the source-revision feature of the release file. I have all the custom extension logic in place to create the revision tracker: $ cat

Re: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build

> On Aug 28, 2017, at 10:18 AM, Vladimir Kozlov > wrote: > > http://cr.openjdk.java.net/~kvn/8186462/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186462 > > We are planning to have Graal as experimental JIT compiler on linux-x64 in > next release. For that

Re: RFR: JDK-8186115 - libelf still referenced after 8172670

> On Aug 15, 2017, at 8:55 PM, Bob Vandette wrote: > > Please review these changes for JDK 10 that remove all dependencies on libelf > from the JDK > build system. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186115 >

Re: [10] RFR: 8182487: Add Unsafe.objectFieldOffset(Class, String)

> On Jun 20, 2017, at 3:14 AM, Claes Redestad wrote: > > Hi, > > as a startup optimization, we can avoid a number of reflective operations on > variouscore classes by adding a specialized objectFieldOffset method taking > Class and String rather than Field: > >

Re: RFR: 8177845: Need a mechanism to load Graal

> On Apr 27, 2017, at 11:51 AM, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 27 Apr 2017, at 18:44, Christian Thalinger <cthalin...@twitter.com> wrote: >> >> Thanks for doing this. I have a hard time following what’s happening :-) >> &g

Re: RFR: 8177845: Need a mechanism to load Graal

71) >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> java

Re: RFR: 8177845: Need a mechanism to load Graal

> On Apr 19, 2017, at 9:27 AM, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 19 Apr 2017, at 21:04, Mandy Chung <mandy.ch...@oracle.com> wrote: >> >> >>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger <cthalin...@twitter.com&g

Re: RFR: 8177845: Need a mechanism to load Graal

les. This all makes sense but where is the restriction that only jdk.internal.vm.compiler can use jdk.vm.ci.services? After all, this is a security issue. > > Mandy > >> On Apr 19, 2017, at 11:24 AM, Christian Thalinger <cthalin...@twitter.com> >> wrote: >&g

Re: RFR: 8177845: Need a mechanism to load Graal

I lost track a bit but why are we exporting jdk.vm.ci.services to the world now? module jdk.internal.vm.ci { -exports jdk.vm.ci.services to jdk.internal.vm.compiler; +exports jdk.vm.ci.services; > On Apr 18, 2017, at 9:16 PM, Doug Simon wrote: > > (adding

Re: What to pass to --with-custom-make-dir?

> On Mar 6, 2017, at 10:17 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > > On 2017-03-07 03:22, David Holmes wrote: >> On 7/03/2017 6:32 AM, Christian Thalinger wrote: >>> >>>> On Mar 6, 2017, at 8:51 AM, Christia

Re: What to pass to --with-custom-make-dir?

> On Mar 6, 2017, at 8:51 AM, Christian Thalinger <cthalin...@twitter.com> > wrote: > > >> On Mar 3, 2017, at 4:09 PM, David Holmes <david.hol...@oracle.com> wrote: >> >> Hi Christian, >> >> I think you need to pass an absolute directory,

Re: What to pass to --with-custom-make-dir?

t;> >> I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more >> appropriate >> venue for this discussion. >> >>-Rob >> >> On 03/03/17 10:19, Christian Thalinger wrote: >>> At Twitter we are using the custom extension

Re: Running jaotc with an external Graal

> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: > > On 14/02/17 14:37, Alan Bateman wrote: >> --patch-module can be used to patch any module in the boot layer. So if >> you are looking to override or add classes then --patch-module should work. > > Aha! Thanks, Does it?

Re: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too)

This is amazing! Awesome work. I’m glad this got done so soon. > On Feb 8, 2017, at 9:29 AM, Bob Vandette wrote: > > SUMMARY: > > Please review the following set of changes that adds Ahead-of-time > compilation support for Mac OSX and > Windows x64 in JDK 10.

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: > >> >> On 26 Jan 2017, at 17:55, Mandy Chung wrote: >> >> >>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>> jdk.vm.compiler is defined by the application

Re: JEP 158 support for JIT

> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: > > Thanks Vladimir, > >> Definitely not in JDK 9. And I can't say when it could be done or done at >> all. > > I hope this feature will be implemented ASAP. You can always contribute an implementation. Shouldn’t be

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

> On Oct 28, 2016, at 11:23 AM, Mandy Chung wrote: > >> >> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov >> wrote: >> >> Thank you, Mandy >> >> On 10/28/16 1:31 PM, Mandy Chung wrote: >>> On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

> On Oct 27, 2016, at 8:12 AM, Vladimir Kozlov <vladimir.koz...@oracle.com> > wrote: > > On 10/27/16 10:55 AM, Christian Thalinger wrote: >> >>> On Oct 27, 2016, at 2:40 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: >>> >>> >

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

> On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote: > > > > On 2016-10-27 02:45, Vladimir Kozlov wrote: >> AOT JEP: >> https://bugs.openjdk.java.net/browse/JDK-8166089 >> Subtask: >> https://bugs.openjdk.java.net/browse/JDK-8166416 >> Webrev: >>

Re: [9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

> On Oct 24, 2016, at 9:01 PM, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 24 Oct 2016, at 23:24, Christian Thalinger <cthalin...@twitter.com> wrote: >> >> >>> On Oct 24, 2016, at 3:48 AM, Erik Joelsson <erik.joels...@orac

Re: [9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

pot-compiler-dev/2016-October/024743.html> > > On 2016-10-19 21:54, Igor Veresov wrote: >> >>> On Oct 19, 2016, at 12:47 PM, Christian Thalinger <cthalin...@twitter.com >>> <mailto:cthalin...@twitter.com>> wrote: >>> >>>

Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd

src/share/vm/runtime/globals.hpp - develop_pd(bool, ImplicitNullChecks, \ + diagnostic_pd(bool, ImplicitNullChecks, \ "Generate code for implicit null checks") \ Align the \ > On May

Re: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions

> On May 4, 2016, at 1:48 PM, Artem Smotrakov > wrote: > > Hello, > > Please review two small patches for jdk and hotspot repos which add array > bound checks to functions which return a length of bytecode instruction. > > Please see details in

Re: ClassValue perf?

> On May 6, 2016, at 4:48 AM, Michael Haupt wrote: > > Hi Peter, > > thank you. I've run the full benchmark in my setup and uploaded the updated > cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/ > . > >

Re: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86

> On Apr 14, 2016, at 6:41 AM, Mikael Vidstedt > wrote: > > > Please review the following change which removes the "client" VM from the > default JIB build profile Is there some public documentation about JIB? A quick search only showed a few JBS bugs that

Re: RFR: JDK-8152666: The new Hotspot Build System

for now. > > /Erik > > On 2016-04-06 03:23, Christian Thalinger wrote: >> >>> On Apr 5, 2016, at 8:10 AM, Daniel D. Daugherty >>> <daniel.daughe...@oracle.com <mailto:daniel.daughe...@oracle.com>> wrote: >> >> … >> >

Re: RFR: JDK-8152666: The new Hotspot Build System

> On Apr 5, 2016, at 8:10 AM, Daniel D. Daugherty > wrote: … > make/Main.gmk >No comments other than the 'hotspot-ide-project' target >looks interesting... Btw. there is already support to generate IDE configurations today via mx:

Re: RFR: JDK-8151656: Minor tweaks to old Hotspot build to ease comparison with new

gt; > With these changes, we can do very clean comparisons on Linux, Solaris and > Macosx. This helps the new hotspot build immensely, but will also be good in > the future as we have a very convenient way of verifying build changes that > shouldn't affect the built output. Now th

Re: RFR: JDK-8151656: Minor tweaks to old Hotspot build to ease comparison with new

> On Mar 15, 2016, at 12:06 AM, Erik Joelsson wrote: > > Any chance I could get a second review on this? Preferably from the hotspot > team. It’s not quite obvious to me what the __FILE__ change is. Maybe an example would help. > > /Erik > > On 2016-03-11 18:16,

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev <aleksey.shipi...@oracle.com> > wrote: > > On 02/20/2016 01:40 AM, Christian Thalinger wrote: >>> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.r...@oracle.com> wrote: >>> On Feb 19, 2016, at 9:57 AM,

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.r...@oracle.com> wrote: > > On Feb 19, 2016, at 9:57 AM, Christian Thalinger > <christian.thalin...@oracle.com <mailto:christian.thalin...@oracle.com>> > wrote: >> >> Why don’t you change the valu

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 4:05 AM, Peter Levart wrote: > > Hi, > > Just a stupid question. > > Your comment in String: > > 140 * @implNote Note this field is not {@link Stable}, because we want > 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

/8141615/jdk/webrev.04/ > > -Konstantin > > On 12/15/2015 08:36 PM, Christian Thalinger wrote: >> >>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >>> <konstantin.she...@oracle.com <mailto:konstantin.she...@oracle.com>> wrote: >>> &

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

/jdk/vm/ci/sparc/SPARCKind.java#l27> and either do a simple linear search to find the entry or build up a table like the HotSpotConstantPool example above. > > -Konstantin > > On 12/15/2015 06:23 AM, Christian Thalinger wrote: >> >>> On Dec 11, 2015, at 1:54 A

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

hods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>> getNameAndTyp

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

PI, I think it's better to decompose the API, i.e. to have a > method > int getInvokedynamicRefNameAndTypeIndex(int index) > that returns the nameAndType index and to reuse > getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. > > cheers, > Rémi &

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

[CC'ing core-libs-dev] > On Nov 13, 2015, at 4:55 AM, Konstantin Shefov > wrote: > > Hello > > Please review an enhancement to add three new methods to > sun.reflect.ConstantPool class. > The following methods are suggested: > > public String[]

Re: JFokus VM Tech Day 2016

> On Nov 11, 2015, at 3:37 PM, John Rose wrote: > > On Nov 11, 2015, at 12:35 AM, Marcus Lagergren > wrote: >> >> bare silicone magic > > That extra E moves the venue from Santa Clara to Las Vegas. LOL! Too good.

Re: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion excluding micro

> On Nov 4, 2015, at 8:21 AM, Volker Simonis wrote: > > Hi, > > can somebody please review and sponsor the following tiny build fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/ > https://bugs.openjdk.java.net/browse/JDK-8141416 > > Building hotspot

Re: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces

> On Oct 25, 2015, at 10:34 PM, Ioi Lam wrote: > > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/ Looks good. I’m sure you asked, who is still using this script? > > Bug: hotspot/make/hotspot.script cannot

Re: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug

any code so I went ahead and did it in the HotSpot Makefiles. Do you want to add a check in configure with this bug or a separate one? > > /Erik > > On 2015-10-21 21:46, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8140091 >> http://

Re: 8139891: Prepare Unsafe for true encapsulation

> On Oct 22, 2015, at 6:31 AM, Paul Sandoz wrote: > > Hi Chris, > > This looks like a good first step. I am sure hotspot devs will have more > concrete review comments, but i like the way the method aliasing (copying the > same technique StrictMath -> Math) avoids any

Re: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes

Thanks, Erik. > On Oct 20, 2015, at 9:51 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Looks good to me. > > /Erik > > On 2015-10-20 22:19, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139935 >> >> The

RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug

https://bugs.openjdk.java.net/browse/JDK-8140091 http://cr.openjdk.java.net/~twisti/8140091/webrev/ There is a bit more context in JIRA but the bottom line is that we shouldn’t be building the JDK with GCC 4.1.1. We have a workaround in just one place but that doesn’t mean the bug doesn’t show

RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes

https://bugs.openjdk.java.net/browse/JDK-8139935 The reason this “works” for a non-bootcycle build is because a JDK 9 javac won't enforce the “hidden packages” rules when running on a non-JDK 9 platform. diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk ---

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

> On Oct 19, 2015, at 8:09 AM, Bob Vandette wrote: > > Here’s the updated set of webrev’s that address two issues: > > 1. Move jni_util.h out of jawt.h > 2. Christians concern over using a single variable name for Makefile and > C/C++ logic. Thanks. Looks good to

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

> On Oct 19, 2015, at 8:09 AM, Bob Vandette wrote: > > Here’s the updated set of webrev’s that address two issues: > > 1. Move jni_util.h out of jawt.h > 2. Christians concern over using a single variable name for Makefile and > C/C++ logic. Thanks. Looks good to

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

Copy-pasting the comment I made earlier (internally): >> make/bsd/makefiles/gcc.make: >> >> + ifeq ($(BUILD_STATIC),true) >> + CXXFLAGS += -DSTATIC_BUILD >> + CFLAGS += -DSTATIC_BUILD >> >> Can we use the same name everywhere? > > We were trying to differentiate Makefile options from compile

Re: RFR: JDK-8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file

($(CD) $(GENSRC_DIR)/META-INF/services && \ > +for i in $$($(LS) *.tmp); do \ > + $(MV) $$i $${i%.tmp}; \ > done) > $(TOUCH) $@ > > /Erik > > On 2015-10-08 04:42, Christian Thalinger wrote: >>> On Oct 5, 2015, at 2:47 AM, Magnu

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

Copy-pasting the comment I made earlier (internally): >> make/bsd/makefiles/gcc.make: >> >> + ifeq ($(BUILD_STATIC),true) >> + CXXFLAGS += -DSTATIC_BUILD >> + CFLAGS += -DSTATIC_BUILD >> >> Can we use the same name everywhere? > > We were trying to differentiate Makefile options from compile

Re: CLANG special case

I’ve assigned the bug to me and will verify… > On Oct 6, 2015, at 9:23 AM, Jim Laskey (Oracle) > wrote: > > Since we are will to live with the de-optimization now, we should just remove > the condition until proven otherwise. > > >> On Oct 6, 2015, at 4:17 PM,

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

evs. Maybe he did something different with the top-level one. > > Regards, > Volker > > > On Thu, Sep 17, 2015 at 10:32 PM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: >> Since there are no objections I’m going to push this… >> >

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

Since there are no objections I’m going to push this… http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf > On Sep 16, 2015, at 3:05 PM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: > > I would like to add this change: > > diff -r 2

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > On 2015-09-14 09:24, Christian Thalinger wrote: >> The JEP itself can be found here: >> >> https://bugs.openjdk.java.net/browse/JDK-8062493 >> <htt

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

> On Sep 16, 2015, at 10:11 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > On 2015-09-16 18:52, Christian Thalinger wrote: >>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie >>> <magnus.ihse.bur...@oracle.com> wrote: >>>

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

> On Sep 16, 2015, at 6:52 AM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: > > >> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie >> <magnus.ihse.bur...@oracle.com> wrote: >> >> On 2015-09-14 09:24, Christian Thali

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

rash logs if this experimental feature was turned on. > On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> > wrote: > > I updated top and hotspot webrev with latest (build) changes. > > Vladimir > > On 9/16/15 2:28 PM, Christian Thaling

Re: JEP 248: Make G1 the Default Garbage Collector

On Apr 30, 2015, at 7:29 AM, Uwe Schindler uschind...@apache.org wrote: Hi Kirk, hi Mark, the Lucene/Solr/Elasticsearch people still recommend to their users to not use G1GC, although for this type of application (full text search with the requirement for very low response times and no

Re: ClassValue perf?

On Apr 24, 2015, at 2:17 PM, John Rose john.r.r...@oracle.com wrote: On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter head...@headius.com wrote: Hey folks! I'm wondering how the performance of ClassValue looks on recent OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so

Re: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586

On Feb 4, 2015, at 3:31 AM, Daniel Fuchs daniel.fu...@oracle.com wrote: Hi, Please find below a fix for: 8072450: 9-dev build failed on elinux-i586 and rlinux-i586 My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev yesterday is causing a build failure in the

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Since you’re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? On Feb 4, 2015, at 7:04 AM, Roland Westrelin roland.westre...@oracle.com wrote: buildreplayjars sometimes fail with an exception and I think that's caused by the lack of

Re: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586

On Feb 4, 2015, at 9:44 AM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 04/02/15 17:21, Christian Thalinger wrote: -const jlong MAX_DIFF_SECS = 0x01; // 2^32 +const jlong MAX_DIFF_SECS = 0x01LL; // 2^32 Don’t use LL directly; we have a compiler-dependent macro

Re: Invokedynamic and recursive method call

Trying to remember compiler implementation details this sounds reasonable and is a bug (or an enhancement, actually ;-). Can someone file a bug? On Jan 7, 2015, at 10:07 AM, Charles Oliver Nutter head...@headius.com wrote: This could explain performance regressions we've seen on the

Re: Invokedynamic and recursive method call

On Jan 29, 2015, at 4:48 PM, John Rose john.r.r...@oracle.com wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr mailto:fo...@univ-mlv.fr wrote: But if fibo is called through an invokedynamic, instead of emitting a direct call to fibo, the JIT generates a code that push

Re: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature

40 public static int[] getAvailableCompilationLevels() { 41 if (System.getProperty(java.vm.info).startsWith(interpreted )) { 42 return new int[0]; 43 } Wouldn’t it be better to check the UseCompiler flag instead? On Dec 19, 2014, at 11:03 AM, Dmitrij

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: Staffan, That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. Do we really want more repositories? Here's the file counts

Re: RFR: AARCH64: Top-level JDK changes

On Nov 19, 2014, at 12:56 AM, Erik Joelsson erik.joels...@oracle.com wrote: On 2014-11-18 19:09, Christian Thalinger wrote: On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-18 01:59, Christian Thalinger wrote: On Nov 17, 2014, at 4:11 AM

Re: RFR: AARCH64: Top-level JDK changes

On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-18 01:59, Christian Thalinger wrote: On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-14 21:44, Dean Long wrote: The distribution exception

Re: RFR: AARCH64: Top-level JDK changes

On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-14 21:44, Dean Long wrote: The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that you are

Re: RFR: AARCH64: Top-level JDK changes

On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-10 11:32, Volker Simonis wrote: On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson erik.joels...@oracle.com wrote: On 2014-11-10 10:27, Volker Simonis wrote: On Mon, Nov 10, 2014 at 9:08 AM,

Re: RFR: AARCH64: Top-level JDK changes

On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http

Re: RFR: AARCH64: Top-level JDK changes

On Nov 7, 2014, at 10:10 AM, Christian Thalinger christian.thalin...@oracle.com wrote: On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first

Re: RFR: AARCH64: Top-level JDK changes

On Nov 7, 2014, at 10:19 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 06:10 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley

Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

On Nov 3, 2014, at 12:41 PM, David Chase david.r.ch...@oracle.com wrote: On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote: Hi David, I was thinking about the fact that java.lang.invoke code is leaking into java.lang.Class. Perhaps, If you don't mind rewriting the

Re: MemberName$Factory.resolve() and the Eclipse debugger.

On Oct 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: When we’ve tried to debug some of our Java core in the context of running a large application we’ve been seeing long pauses (sometime very long pauses of over a minute) due to

Re: MemberName$Factory.resolve() and the Eclipse debugger.

On Oct 29, 2014, at 10:06 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: On 29/10/2014 16:55, Christian Thalinger christian.thalin...@oracle.com wrote: On Oct 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote

Re: Loopy CallSite

On Jul 16, 2014, at 11:40 AM, Remi Forax fo...@univ-mlv.fr wrote: On 07/16/2014 07:38 PM, Vladimir Ivanov wrote: Remi, The problem is that for every iteration you create new call site for(int i=0; i100_000; i++) { new LoopyCS().getTarget().invokeExact(1_000); }

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

On Jun 30, 2014, at 1:06 PM, Coleen Phillimore coleen.phillim...@oracle.com wrote: On 6/30/14, 3:50 PM, Christian Thalinger wrote: private Class(ClassLoader loader) { // Initialize final field for classLoader. The initialization value of non-null // prevents

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com wrote: On 6/30/14, 3:50 PM, Christian Thalinger wrote: private Class(ClassLoader loader) { // Initialize final field for classLoader. The initialization value of non-null // prevents

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Tobias, I'll take care of it. Are you also taking care of the backports? Best regards, Vladimir Ivanov On 6/2/14 10:04 AM, Tobias Hartmann wrote: On 28.05.2014 12:48, Vladimir Ivanov wrote: Looks good.

hg: jdk7u/jdk7u-dev/hotspot: 2 new changesets

Changeset: b60f95bce6c2 Author:mikael Date: 2014-05-29 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/b60f95bce6c2 8043205: Incorrect system traps.h include path Reviewed-by: kvn, dholmes ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp Changeset:

hg: jdk7u/jdk7u-dev/hotspot: 2 new changesets

Changeset: f290ac92cb22 Author:mikael Date: 2014-04-29 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/f290ac92cb22 8022070: Compilation error in stubGenerator_sparc.cpp with some compilers Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp

Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle

Looks good. Would be good to put a FIXME on the comment as well so we don’t forget to remove it. On May 26, 2014, at 12:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8034935 http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00

RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused

https://bugs.openjdk.java.net/browse/JDK-8032606 http://cr.openjdk.java.net/~twisti/8032606/webrev.00 8032606: ClassValue.ClassValueMap.type is unused Reviewed-by:

Re: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused

Thanks, John and Vladimir. On May 15, 2014, at 2:46 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Looks good. Best regards, Vladimir Ivanov On 5/15/14 9:48 PM, Christian Thalinger wrote: https://bugs.openjdk.java.net/browse/JDK-8032606 http://cr.openjdk.java.net/~twisti

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

::interp_only_mode_offset()), 0); +__ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); __ jcc(Assembler::zero, skip_jvmti_method_exit, true); save_native_result(masm, ret_type, stack_slots); On 14 maj 2014, at 00:21, Christian Thalinger christian.thalin...@oracle.com wrote

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

. This allows only one thread to set the LambdaForm that is then being used by all instances of the invokeExact. *Testing* - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) - Nashorn + Octane - JPRT Many thanks to Christian Thalinger and Vladimir Ivanov! Best, Tobias [1] Call sequence

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

Since: int _interp_only_mode; is an int field I would prefer to actually read the value as an int instead of just a byte on x86: +__ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); Otherwise this looks good. On May 13, 2014, at 11:30 AM, Staffan Larsen

Re: FORK

On Apr 23, 2014, at 9:44 PM, Charles Oliver Nutter head...@headius.com wrote: What would it take to make Hotspot forkable? Obviously we'd need to pause all VM threads and restarting them on the other side (or perhaps a prefork mode that doesn't spin up threads?) but I know there's challenges

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Apr 3, 2014, at 9:44 PM, John Rose john.r.r...@oracle.com wrote: On Apr 3, 2014, at 6:33 PM, Christian Thalinger christian.thalin...@oracle.com wrote: Of course they are popular because these are the type names. There is no type L; it’s an object. I don’t understand why we have

  1   2   3   4   5   6   7   8   9   10   >