Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13]

2024-09-13 Thread Roberto Castañeda Lozano
On Thu, 12 Sep 2024 15:38:18 GMT, Thomas Stuefe wrote: >> src/hotspot/share/opto/lcm.cpp line 272: >> >>> 270: const TypePtr* tptr; >>> 271: if ((UseCompressedOops || UseCompressedClassPointers) && >>> 272: (CompressedOops::shift() == 0 || >>> CompressedKlassPointers

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13]

2024-09-13 Thread Roberto Castañeda Lozano
On Thu, 12 Sep 2024 11:46:35 GMT, Roberto Castañeda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert accidental change of UCOH default > > src/hotspot/share/cds/filemap.cpp line 2457: > >> 2455:

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Roman Kennke
> This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) > #20603 and #20605, plus the Tiny Class-Pointers parts that have been > previously missing. > > Main changes: > - Introduction of the (

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Roman Kennke
On Fri, 13 Sep 2024 07:54:30 GMT, Roberto Castañeda Lozano wrote: >> src/hotspot/share/cds/filemap.cpp line 2457: >> >>> 2455: compressed_oops(), >>> compressed_class_pointers()); >>> 2456: if (compressed_oops() != UseCompressedOops || >>> compressed_class_pointers

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Thomas Stuefe
On Tue, 10 Sep 2024 12:19:32 GMT, Coleen Phillimore wrote: >> This is tricky. We are already deep in initialization and have done a couple >> of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I >> *think* we could still go with -UseCCP, but I wonder whether this is wise. >>

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Thomas Stuefe
On Tue, 10 Sep 2024 12:13:58 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 243: >> >>> 241: } else { >>> 242: >>> 243: // In legacy mode, we try, in order of preference: >> >> Can you not use the word 'legacy' here? Maybe in "non-compact object header >>

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Stefan Karlsson
On Fri, 13 Sep 2024 08:21:54 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) >> #20603 and #20605, plus the Tiny Class-Pointers parts that have been >> prev

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Stefan Karlsson
On Mon, 9 Sep 2024 12:17:17 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/oop.cpp line 230:

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Thomas Schatzl
On Fri, 13 Sep 2024 09:00:32 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/oop.cpp line 230: >> >>> 228: // disjunct below to fail if the two comparands are computed across >>> such >>> 229: // a concurrent change. >>> 230: return Universe::heap()->is_stw_gc_active() && >>> klass

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Thomas Stuefe
On Tue, 10 Sep 2024 12:35:42 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 116: >> >>> 114: _range = end - _base; >>> 115: >>> 116: DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);) >> >> Can you refactor so the aarch64 path runs this same code

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Stefan Karlsson
On Fri, 13 Sep 2024 11:10:58 GMT, Thomas Schatzl wrote: >> That bug doesn't fix all cases where the the length field is modified. > > Which ones are remaining? JDK-8337709 implemented the same change for G1 GC > before JDK-8311163. > > The full collectors/g1 marking do not modify the length fie

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Stefan Karlsson
On Fri, 13 Sep 2024 12:47:09 GMT, Stefan Karlsson wrote: >> Which ones are remaining? JDK-8337709 implemented the same change for G1 GC >> before JDK-8311163. >> >> The full collectors/g1 marking do not modify the length fields but have >> multiple separate queues which is a different issue. I

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Roman Kennke
On Fri, 13 Sep 2024 09:39:23 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Hide log timestamps in test to prevent false failures > > src/hotspot/share/oops/oop.inline.hpp line 295: > >> 293:

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Roman Kennke
On Fri, 13 Sep 2024 09:31:39 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Hide log timestamps in test to prevent false failures > > src/hotspot/share/oops/oop.hpp line 363: > >> 361:

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15]

2024-09-13 Thread Roman Kennke
> This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) > #20603 and #20605, plus the Tiny Class-Pointers parts that have been > previously missing. > > Main changes: > - Introduction of the (

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14]

2024-09-13 Thread Stefan Karlsson
On Fri, 13 Sep 2024 12:53:29 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/oop.inline.hpp line 295: >> >>> 293: // Used by scavengers >>> 294: void oopDesc::forward_to(oop p) { >>> 295: assert(cast_from_oop(p) != this, >> >> Do we really need the cast here? > > Yes, otherwise compiler co

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8]

2024-09-13 Thread Thomas Schatzl
On Fri, 13 Sep 2024 12:48:53 GMT, Stefan Karlsson wrote: >> If you've already fixed this for GC then I agree that we could remove this. > > This seems like something that should be done as a separate patch that gets > pushed before this PR. Will remove in JDK-8340119. - PR Review

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Daniel Fuchs
On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter wrote: >> Moved to `NTLMAuthentication` static initializer. 853d349 > > @dfuch Would you please check whether the change at line 71 in the updated > version of `NTLMAuthentication` is the correct place for this load? hmm... I don't see any iss

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Daniel Fuchs
On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs wrote: >> @dfuch Would you please check whether the change at line 71 in the updated >> version of `NTLMAuthentication` is the correct place for this load? > > hmm... I don't see any issue in adding the load call to `NTLMAuthentication` > but I'm

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Brian Burkhalter
On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote: >> hmm... I don't see any issue in adding the load call to >> `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect >> that libnet would have been loaded before we reach NTLMAuthentication. > > I wonder - do you see any f

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Brian Burkhalter
On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote: >> I wonder - do you see any failure if you don't load libnet from there? > > Yes, there was an `UnsatisfiedLinkError` in the native method > `isTrustedSiteAvailable()` in `NTLMAuthentication`. > [...] I'd expect that libnet would have b

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Daniel Fuchs
On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter wrote: >> Yes, there was an `UnsatisfiedLinkError` in the native method >> `isTrustedSiteAvailable()` in `NTLMAuthentication`. > >> [...] I'd expect that libnet would have been loaded before we reach >> NTLMAuthentication. > > In the (as of no

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Brian Burkhalter
On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote: >>> [...] I'd expect that libnet would have been loaded before we reach >>> NTLMAuthentication. >> >> In the (as of now) penultimate webrev 4f47d5a (Merge), >> `WindowsNativeDispatcher` loaded it during boot phase 2. I think that >> withou

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Daniel Fuchs
On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter wrote: >> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded >> by HttpURLConnection, which should have triggered the loading of libnet long >> before it cares about NTLM. > > I would have to check. The failure I observe

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5]

2024-09-13 Thread Brian Burkhalter
On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote: >> I would have to check. The failure I observed occurred in both of these tests >> >> test/jdk/sun/net/www/protocol/http/NoNTLM.java >> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java >> >> and nowhere else. > > I see. The test

Re: RFR: 8340075: Autoconf bundle cannot run on read-only filesystem

2024-09-13 Thread Mikael Vidstedt
On Thu, 12 Sep 2024 22:33:43 GMT, Erik Joelsson wrote: > The autoconf launcher script in the autoconf bundle created by > `make/devkit/createAutoconf.sh` currently writes a config file into the > bundle installation dir every time it runs. This prevents it from functioning > when installed on

Integrated: 8340075: Autoconf bundle cannot run on read-only filesystem

2024-09-13 Thread Erik Joelsson
On Thu, 12 Sep 2024 22:33:43 GMT, Erik Joelsson wrote: > The autoconf launcher script in the autoconf bundle created by > `make/devkit/createAutoconf.sh` currently writes a config file into the > bundle installation dir every time it runs. This prevents it from functioning > when installed on

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7]

2024-09-13 Thread Magnus Ihse Bursie
On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file >> interaction from the libnio native library to the libjava native library on >> Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request in

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8]

2024-09-13 Thread Brian Burkhalter
> This proposed change would move the native objects required for NIO file > interaction from the libnio native library to the libjava native library on > Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7]

2024-09-13 Thread Brian Burkhalter
On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8337143: Clean up to address reviewer comments > > make/modules/java.base/lib/CoreLibraries.gmk line 68: > >