On Thu, 30 Mar 2023 16:05:08 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
> Minor changes to the build system to recognize and warn that an incompatible
> toolchain is detected.
Tyler Steele has updated the pull request incrementally with one additional
commit since the last revision:
Change min xlx FP level to 11
-
Changes:
- all: https://git.openj
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer and compare it to null. We can simply read `eetop`
> dir
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Mon, 3 Apr 2023 12:32:35 GMT, David Holmes wrote:
> > This looks interesting. I think it is time to rename eetop to
> > javaThreadAddr ...
>
> Feel free to file a RFE but not as part of this PR. :)
Well, when this thing is considered in isolation, it changes the clear
`isAlive0()` call to
On Sun, 2 Apr 2023 06:59:02 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
>> fla
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Sun, 2 Apr 2023 06:59:02 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
>> fla
On 3/04/2023 9:27 pm, Simon Roberts wrote:
Agreed, I believe there should be an hb relationship with this, if the
target is not alive.
You are both right - I did not recall the hb relationship between the
last action of a thread and a call to isAlive that returns false. The
existing code does
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Mon, 3 Apr 2023 11:39:43 GMT, Aleksey Shipilev wrote:
> This looks interesting. I think it is time to rename eetop to javaThreadAddr
> ...
Feel free to file a RFE but not as part of this PR. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494240185
On Mon, 3 Apr 2023 10:47:55 GMT, Quan Anh Mai wrote:
> May I ask if we need some form of memory order here? Maybe an aquiring load
> is necessary?
What is it that you think needs ordering?
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494238641
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Mon, 3 Apr 2023 07:53:00 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment from AlanB
>
> src/java.base/share/classes/java/lang/Thread.java line 231:
>
>> 229: /* Reserved for exclus
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer and compare it to null. We can simply read `eetop`
> dir
On Tue, 21 Mar 2023 01:24:44 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of an enhancement that adds the option
> preserve-repository=true/false to -XX:FlightRecorderOptions and jcmd
> JFR.configure. When set to true, chunk files in the repository will not be
> removed by the JVM
On Mon, 3 Apr 2023 07:17:59 GMT, David Holmes wrote:
> We have the strange situation where calling `t.isAlive()` on a
> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
> its `JavaThread` pointer an
We have the strange situation where calling `t.isAlive()` on a
`java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`)
where the VM then examines the `eetop` field of `t` to extract its `JavaThread`
pointer and compare it to null. We can simply read `eetop` directly in
`
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 18:56:20 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of an enhancement that adds the option
>> preserve-repository=true/false to -XX:FlightRecorderOptions and jcmd
>> JFR.configure. When set to true, chunk files in the repository will not be
>> removed by th
On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg wrote:
>> API changes for the FFM API (third preview)
>>
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>>
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.ht
25 matches
Mail list logo
