On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote:
> This one is not just to get rid of a warning. We get real test errors because
> malloc gets replaced by vec_malloc in log tags.
That does not invalidate my argument, nor does it answer my question. Those
test errors could be also fixed by
On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote:
> This one is not just to get rid of a warning. We get real test errors because
> malloc gets replaced by vec_malloc in log tags.
That does not invalidate my argument, nor does it answer my question. Those
test errors could be also fixed by
On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Wed, 24 May 2023 14:30:10 GMT, Volker Simonis wrote:
>>> > Sorry, but I don't understand this argument. If we do a short read we
>>> > will work with corrupted ChildStuff and SpawnInfo
>>> > structures. This can in the extreme case execute arbitrary code (e.g. if
>>> > ChildStuff.argv is not
On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Thu, 12 Jan 2023 16:52:50 GMT, Thomas Stuefe wrote:
>> Curious, I always thought we do ArrayAllocator - using mmap for larger
>> allocations - to prevent memory retention for libc variants whose allocators
>> are "grabby", i.e. which don't promptly return me
On Thu, 19 Jan 2023 17:23:19 GMT, Justin King wrote:
>> Remove abstraction that is a holdover from Solaris. Direct usages of
>> `MmapArrayAllocator` have been switched to normal `malloc`. The
>> justification is that none of the code paths are called from signal
>> handlers, so using `mmap` di
On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe wrote:
> Trivial fix for a small problem.
>
> jspawnhelper gets handed several file descriptors as arguments. The buffer
> size for this string is too small (7 chars per fd) to print out every
> conceivable int. This will overun t
On Thu, 18 May 2023 13:46:54 GMT, Roger Riggs wrote:
>> Thomas Stuefe has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two addi
still
> printable within the limits of this buffer. It is possible to get more fds
> per process, but only via kernel patch. But we still should not rely on that.
> And there is also still MacOS using the same mechanism.
Thomas Stuefe has updated the pull request with a new targe
On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe wrote:
> Trivial fix for a small problem.
>
> jspawnhelper gets handed several file descriptors as arguments. The buffer
> size for this string is too small (7 chars per fd) to print out every
> conceivable int. This will overun t
On Wed, 17 May 2023 16:12:15 GMT, Volker Simonis wrote:
>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
>>
>>> 488: pid_t resultPid;
>>> 489: int i, offset, rval, bufsize, magic;
>>> 490: char *buf, buf1[24];
>>
>> Since you are here could you please increase buffer
On Wed, 17 May 2023 16:00:23 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
Trivial fix for a small problem.
jspawnhelper gets handed several file descriptors as arguments. The buffer size
for this string is too small (7 chars per fd) to print out every conceivable
int. This will overun the buffer if we happen to have fds larger than (printed
size) 7 characters. This c
On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar wrote:
> s390x needs to be recognised as `S390`. After
> [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was
> getting this PluginException:
>
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
>
On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich
wrote:
> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
>
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum
> constant jdk.internal.util.Architecture.ARM
> at
> jdk.jli
On Wed, 17 May 2023 16:05:58 GMT, Volker Simonis wrote:
>> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
>>
>>> 138: struct stat buf;
>>> 139: /* argv[0] contains the fd number to read all the child info */
>>> 140: int r, fdinr, fdinw, fdout;
>>
>> Since you are h
On Wed, 17 May 2023 12:33:48 GMT, Volker Simonis wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly sta
On Tue, 16 May 2023 12:07:10 GMT, David Holmes wrote:
> > > I wonder if @Martin-Buchholz is able to look at this one?
> > > My concern with changes like this is that they fix an issue but then have
> > > unexpected side-effects themselves.
> >
> >
> > Are there any specific concerns you have?
On Mon, 15 May 2023 16:11:46 GMT, Volker Simonis wrote:
> > 2. I think you don't actually have to hand in the in-pipe-read-end fd
> > number via command line arg, just to have the child to close it. You could
> > just, in the parent, set the fd to FD_CLOEXEC. Since posix_spawn() exec's
> > the
On Tue, 16 May 2023 07:24:31 GMT, David Holmes wrote:
> I wonder if @Martin-Buchholz is able to look at this one?
>
> My concern with changes like this is that they fix an issue but then have
> unexpected side-effects themselves.
Are there any specific concerns you have?
-
PR Com
On Mon, 15 May 2023 18:45:24 GMT, Roger Riggs wrote:
>> Since JDK13, executing commands in a sub-process defaults to the so called
>> `POSIX_SPAWN` launching mechanism (i.e.
>> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
>> using `posix_spawn(3)` to firstly start
On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis wrote:
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to firstly start a
On Mon, 15 May 2023 12:31:49 GMT, Volker Simonis wrote:
> > Looks ok.
> > Is it practical to write a test for this situation? Can I assume you've
> > validated the improvement as a remedy for the observed hangs?
>
> I thought about a test but couldn't come up with a practical way to write it.
On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis wrote:
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to firstly start a
On Mon, 15 May 2023 13:22:12 GMT, Aleksey Shipilev wrote:
> > Thank you for fixing this
>
> Thanks for looking at it. Trivial, right?
Trivial.
-
PR Comment: https://git.openjdk.org/jdk/pull/13981#issuecomment-1547890912
On Mon, 15 May 2023 10:00:42 GMT, Aleksey Shipilev wrote:
> Currently failing at host configuration step with:
>
>
> The following packages have unmet dependencies:
> libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed
> libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) b
On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis wrote:
> Since JDK13, executing commands in a sub-process defaults to the so called
> `POSIX_SPAWN` launching mechanism (i.e.
> `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by
> using `posix_spawn(3)` to firstly start a
On Tue, 2 May 2023 12:23:23 GMT, Julian Waters wrote:
>> Windows no longer uses I64d anywhere in their newer compilers, instead using
>> the conforming lld specifiers. Minor cleanup here in JLI code to reflect that
>
> Julian Waters has updated the pull request incrementally with one additional
On Thu, 4 May 2023 09:26:33 GMT, Andrew Dinn wrote:
> This small change ensures that repeated bytecode rewrites necessitated by
> class pool index updates are applied cumulatively when updating the method
> line number table. The current code applies each change to the original table
> which m
On Mon, 8 May 2023 17:04:29 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Only allow lock-stack verification for owning Java threads or at safepoints
>
> src/hotspot/cpu/arm/c1_MacroAssemble
On Fri, 5 May 2023 16:49:38 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 2 May 2023 22:46:44 GMT, Dean Long wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missing new file
>
> My review applies to the aarch64 changes.
> I have looked at the aarch64 changes twice and the lat
On Thu, 4 May 2023 07:30:49 GMT, Arno Zeller wrote:
> Unless this test is run as root, it needs sudo privileges. If it gets them,
> the test runs fine, but leaves a file with root ownership. So jtreg cannot
> delete it, and you see errors when "make clean" tries to delete it.
> It's best that
On Fri, 28 Apr 2023 07:43:24 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 26 Apr 2023 18:58:13 GMT, Roman Kennke wrote:
>>> @rkennke - I'm planning to do another crawl thru review next week.
>>
>> Thanks! That is greatly appeciated!
>
>> @rkennke - finished my second crawl thru review of 60/68 files changed. I
>> only skipped the RISC-V files since I know nad
On Wed, 26 Apr 2023 18:35:45 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649:
>>
>>> 647:
>>> 648: __ flush();
>>> 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry,
>>> c2i_entry, c2i_un
On Fri, 28 Apr 2023 07:43:24 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>
>> 1801: #ifdef ASSERT
On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland wrote:
> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a
> heuristic to determine whether the question it's answering is "simple" or
>
On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland wrote:
> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a
> heuristic to determine whether the question it's answering is "simple" or
>
On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote:
> This PR combines the "open" and "closed" regions of the CDS archive heap into
> a single region. This significantly simplifies the implementation, making it
> more compatible with non-G1 collectors. There's a net removal of ~1000 lines
> in src
On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote:
> Refactored the way that build time architecture values are mapped to the
> Architecture enum.
Thank you for this, Roger.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537
On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote:
> Refactored the way that build time architecture values are mapped to the
> Architecture enum.
Thank you for this, Roger.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537
On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote:
> Refactored the way that build time architecture values are mapped to the
> Architecture enum.
Thank you for this, Roger.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537
On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote:
> Refactored the way that build time architecture values are mapped to the
> Architecture enum.
Thank you for this, Roger.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537
On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>>
>>> 39: AARCH64(),
>>> 40: RISCV64(),
>>> 41: S390(),
>>
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel
>> in almost te
On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>>
>>> 39: AARCH64(),
>>> 40: RISCV64(),
>>> 41: S390(),
>>
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel
>> in almost te
On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>>
>>> 39: AARCH64(),
>>> 40: RISCV64(),
>>> 41: S390(),
>>
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel
>> in almost te
On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>>
>>> 39: AARCH64(),
>>> 40: RISCV64(),
>>> 41: S390(),
>>
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel
>> in almost te
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote:
> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> > also have PPC big-endian, it is used by AIX (and you can also run Linux
> > with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
>
> So I thin
On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote:
> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> > also have PPC big-endian, it is used by AIX (and you can also run Linux
> > with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
>
> So I thin
On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote:
> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> > also have PPC big-endian, it is used by AIX (and you can also run Linux
> > with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
>
> So I thin
On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote:
> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> > also have PPC big-endian, it is used by AIX (and you can also run Linux
> > with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
>
> So I thin
On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote:
> > What about PPC (big endian)? Used on AIX?
>
> I'm not aware of any code (in OpenJDK) related to big/little endian that is
> derived from `os.arch`.
>
> > On Arm, it may be useful to know whether we built for thumb mode (We
> > recently h
On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote:
> > What about PPC (big endian)? Used on AIX?
>
> I'm not aware of any code (in OpenJDK) related to big/little endian that is
> derived from `os.arch`.
>
> > On Arm, it may be useful to know whether we built for thumb mode (We
> > recently h
On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote:
> > What about PPC (big endian)? Used on AIX?
>
> I'm not aware of any code (in OpenJDK) related to big/little endian that is
> derived from `os.arch`.
>
> > On Arm, it may be useful to know whether we built for thumb mode (We
> > recently h
On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote:
> > What about PPC (big endian)? Used on AIX?
>
> I'm not aware of any code (in OpenJDK) related to big/little endian that is
> derived from `os.arch`.
>
> > On Arm, it may be useful to know whether we built for thumb mode (We
> > recently h
On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote:
>> The point of Architecture is reflect the architecture as supported by the
>> build and the runtime mutually and to reflect dependencies on the target
>> hardware.
>>
>> What did you use as the example that would not compile on the other
>> arc
On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote:
>> The point of Architecture is reflect the architecture as supported by the
>> build and the runtime mutually and to reflect dependencies on the target
>> hardware.
>>
>> What did you use as the example that would not compile on the other
>> arc
On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote:
>> The point of Architecture is reflect the architecture as supported by the
>> build and the runtime mutually and to reflect dependencies on the target
>> hardware.
>>
>> What did you use as the example that would not compile on the other
>> arc
On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote:
>> The point of Architecture is reflect the architecture as supported by the
>> build and the runtime mutually and to reflect dependencies on the target
>> hardware.
>>
>> What did you use as the example that would not compile on the other
>> arc
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Wed, 5 Apr 2023 10:40:54 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 28 Mar 2023 15:05:41 GMT, Justin King wrote:
> This change fixes or skips some NMT tests when running under ASan, as well as
> fixing a leak.
>
> - `allocator_may_return_null=1` is added as the default is `0`, meaning ASan
> will never return `nullptr` and will instead crash. NMT tests
On Mon, 3 Apr 2023 11:05:41 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 4 Apr 2023 12:25:19 GMT, David Holmes wrote:
>> That is done one layer up in InterpreterMacroAssembler::unlock_object.
>
> Thanks @tstuefe . I see at that level if the object doesn't match the top of
> the lock-stack then we take the slow path. But then I'm lost - AFAICS the
> slow path
On Tue, 4 Apr 2023 05:54:09 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739:
>
>> 9737: get_thread(thread);
>> 9738: #endif
>>
On Mon, 3 Apr 2023 05:57:18 GMT, Thomas Stuefe wrote:
> > I wonder about the explicit exclusion of arm. Every other CPU seems to be
> > taken care of, even those Oracle does not maintain. Just curious, was there
> > a special reason for excluding arm?
>
> There is no
On Fri, 31 Mar 2023 15:34:12 GMT, Matias Saavedra Silva
wrote:
> > This obviously breaks arm, since its implementation is missing. I opened
> > https://bugs.openjdk.org/browse/JDK-8305387 to track this. This is
> > unfortunate since it holds work on arm in other areas, in my case for
> > #109
On Fri, 31 Mar 2023 13:54:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 31 Mar 2023 15:24:07 GMT, Thomas Stuefe wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>&
On Fri, 31 Mar 2023 13:54:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> A previous argument against link time optimization support that we have for
>> gcc is that it was extremely slow. After some checks it turns out we are
>> passing rather inefficient flags to gcc in optimized builds. Changing these
>> fl
On Fri, 31 Mar 2023 06:06:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 24 Mar 2023 16:54:59 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/runtime/lockStack.cpp line 42:
>>
>>> 40:
>>> 41: #ifndef PRODUCT
>>> 42: void LockStack::validate(const char* msg) const {
>>
>> Would you also like to check there
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Mon, 27 Mar 2023 02:46:31 GMT, David Holmes wrote:
> > AFAIU, these places now could get outdated information from the contains
> > function: either getting a false positive or a false negative when asking
> > for a given object. But if I understand correctly, this had been the case
> > bef
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 24 Mar 2023 11:36:24 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Fri, 24 Mar 2023 07:28:27 GMT, Jaroslav Bachorik
wrote:
> > Yes, but while JFR interrupts threads too, its sampler runs in its own
> > thread, so the async-safety of the interrupted code should not matter, or?
>
> And this sampling approach is quite subpar when compared with the signal
> b
On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
601 - 700 of 1265 matches
Mail list logo
