RE: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

Hi Jesper, Thanks for opening that issue, if this is implemented it will help a lot! Best regards, Goetz. > -Original Message- > From: Jesper Wilhelmsson > Sent: Thursday, October 1, 2020 11:35 PM > To: Lindenmaier, Goetz > Cc: Leonid Mesnik ; serviceability- >

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

On Thu, 1 Oct 2020 15:02:01 GMT, Vladimir Kempik wrote: > Please review this change for hotspot and one test. > There is few JVMTI callback/event functions in jdk which signature doesn't > match specification. > for example: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv*

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5]

On Fri, 2 Oct 2020 02:40:16 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code >> (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5]

On Fri, 2 Oct 2020 02:40:16 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code >> (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

So I'm confused... this PR is associated with this bug ID: Issue * JDK-8248238 : Implementation of JEP: Windows AArch64 Support and JDK-8248238 is associated with this JEP: JDK-8248496

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

It’s me who made a mistake. This PR should be associated with JEP 388 as you are rightly pointing out. From: Daniel D. Daugherty Sent: Thursday, October 1, 2020 3:05 PM To: Ludovic Henry ; David Holmes ; David Holmes ; Andrew Haley ; Chris Plummer ; Magnus Ihse Bursie ;

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5]

> TestInstanceKlassSize was failing because, for PowerPC, the following code > (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif >

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2]

On Thu, 1 Oct 2020 21:47:01 GMT, Chris Plummer wrote: > My suggestion was to put the comment in the CR. I really don't think there > should be any comment in ProblemList.txt. > This is not an uncommon situation. Tests are often removed from the problem > list simply because they have not been

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

Hi Vladimir, On 2/10/2020 1:09 am, Vladimir Kempik wrote: Please review this change for hotspot and one test. There is few JVMTI callback/event functions in jdk which signature doesn't match specification. for example: static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env,

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

Hi David, > The JEP is not yet targeted so we have to wait for that formality. But once > that happens I can sponsor for you. Perfect, I didn't know about the need for the JEP to be targeted before the merge. > Also note that the PR references the wrong JEP so can you please edit the >

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

Hi, On 2/10/2020 1:48 am, Ludovic Henry wrote: Hi, As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged. The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you. Also note that the PR

Re: Survey : On the jinfo, jmap, jstack serviceability tools

Are the results of this survey now available? -Jaikiran On 16/06/20 1:12 am, Stephen Fitch wrote: > Hello: > > We are considering deprecation and (eventual) removal of the jinfo, > jmap, jstack - (aka “j* tools”) and building out a future foundation > for some aspect of serviceability on jcmd,

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2]

On Thu, 1 Oct 2020 20:35:57 GMT, Ziviani wrote: > > ... I suggest maybe adding a comment there saying that the test was removed > > from the problem list when JDK-8253900 was > > fixed, but should be re-added if JDK-8230664 starts to reproduce again. > > I like this idea because a simple

Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the Skara team to have the bots check this before allowing integration. /Jesper > On 1 Oct 2020, at 23:06, Lindenmaier, Goetz wrote: > > Hi, > > Please open up a dummy copy JBS issue without confidential > information if you

RE: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

Hi, Please open up a dummy copy JBS issue without confidential information if you fix a closed, internal Oracle bug. I missed this before, I only saw it is closed when this was pushed today. It is really annoying to still see closed bugs. I had hoped skara would help to avoid this. Please

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2]

On Thu, 1 Oct 2020 19:22:24 GMT, Chris Plummer wrote: > ... I suggest maybe adding a comment there saying that the test was removed > from the problem list when JDK-8253900 was > fixed, but should be re-added if JDK-8230664 starts to reproduce again. I like this idea because a simple `grep`

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v4]

> TestInstanceKlassSize was failing because, for PowerPC, the following code > (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif >

Re: RFR: 8252537: Updated @exception with @throws [v4]

On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks >> of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2]

On Thu, 1 Oct 2020 16:37:11 GMT, Ziviani wrote: > > If these tests are currently passing with Jose's fix, I suggest to comment > > them out in the problem list with a note > > that we may need to disable them again because of JDK-8230664. This way we > > can test the functionality Jose is

Re: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2]

On Thu, 1 Oct 2020 15:15:09 GMT, Martin Doerr wrote: > If these tests are currently passing with Jose's fix, I suggest to comment > them out in the problem list with a note > that we may need to disable them again because of JDK-8230664. This way we > can test the functionality Jose is fixing

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v3]

> TestInstanceKlassSize was failing because, for PowerPC, the following code > (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif >

RE: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

Hi, As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged. Thank you :) - PR: https://github.com/openjdk/jdk/pull/212

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2]

On Thu, 1 Oct 2020 15:02:55 GMT, Chris Plummer wrote: >>> I think this fix deserves a new JBS issue. It doesn't resolve the rounding >>> problem described in JDK-8230664. It fixes >>> an additional issue. The rounding problem may reoccur when other class >>> layout changes are done. >> >>

RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

Please review this change for hotspot and one test. There is few JVMTI callback/event functions in jdk which signature doesn't match specification. for example: static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) but according to jvmti specs it should

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2]

On Thu, 1 Oct 2020 14:01:29 GMT, Ziviani wrote: > I think this fix deserves a new JBS issue. It doesn't resolve the rounding > problem described in JDK-8230664. It fixes > an additional issue. The rounding problem may reoccur when other class layout > changes are done. Does it still need to

Integrated: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik wrote: > Test fails with -XX:-TieredCompilation because j.l.Object hasn't been used > enough time to trigger compilation. The > default CompileThreshold value is good enough when tiered compilation is > enabled (by default) but not for

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2]

On Thu, 1 Oct 2020 14:01:29 GMT, Ziviani wrote: >> I think this fix deserves a new JBS issue. It doesn't resolve the rounding >> problem described in JDK-8230664. It fixes >> an additional issue. The rounding problem may reoccur when other class >> layout changes are done. > >> I think this

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2]

On Thu, 1 Oct 2020 12:21:22 GMT, Martin Doerr wrote: > I think this fix deserves a new JBS issue. It doesn't resolve the rounding > problem described in JDK-8230664. It fixes > an additional issue. The rounding problem may reoccur when other class layout > changes are done. Totally agreed.

Re: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2]

On Thu, 1 Oct 2020 00:19:09 GMT, Serguei Spitsyn wrote: >> Ziviani has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains >> one commit: >> 8230664: Fix TestInstanceKlassSize >> >> The code hasStoredFingerprint() at

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8]

> On Oct 1, 2020, at 5:53 AM, Erik Österlund > wrote: > > >> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) >> onsrc/hotspot/share/runtime/frame.cpp >> 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); >> >> Something to consider is that

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8]

On Thu, 1 Oct 2020 09:50:45 GMT, Erik Österlund wrote: >> Marked as reviewed by rehn (Reviewer). > >> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) on >> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_ >> I've only looked at scattered pieces, but what I've looked

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8]

On Tue, 29 Sep 2020 16:09:48 GMT, Robbin Ehn wrote: >> Erik Österlund has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now >> contains 12 commits: >> - Review: Move barrier detach >> - Review: Remove assert that has outstayed its welcome >>

Re: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9]

On Thu, 1 Oct 2020 01:31:04 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v9]

> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack > Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a > frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the