On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters wrote:
>> src/hotspot/os/windows/os_windows.hpp line 35:
>>
>>> 33: class Thread;
>>> 34:
>>> 35: static unsigned __stdcall thread_native_entry(Thread*);
>>
>> Why was this removed? This is needed to correctly specify the call sequence
>> for th
On Mon, 14 Nov 2022 01:39:17 GMT, Julian Waters wrote:
>> src/hotspot/share/utilities/debug.hpp line 172:
>>
>>> 170: int status, const char* detail);
>>> 171: ATTRIBUTE_PRINTF(4, 5)
>>> 172: void report_fatal(VMErrorType error_type, const char* file, int line,
>>> c
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
java/util/concurrent/forkjoin/AsyncShutdownNow.java takes ~40s as each test
uses a delay of 5s before it invokes shutdownNow. The test will run in <1s if
changed to poll the thread state and invoke shutdownNow when the thread waits.
The update temporarily disables testInvokeAny because of a susp
On Fri, 4 Nov 2022 14:13:42 GMT, Alan Bateman wrote:
> java/util/concurrent/forkjoin/AsyncShutdownNow.java takes ~40s as each test
> uses a delay of 5s before it invokes shutdownNow. The test will run in <1s if
> changed to poll the thread state and invoke shutdownNow when the thread waits.
>
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
On Mon, 14 Nov 2022 07:17:01 GMT, Alan Bateman wrote:
> A comment from the PR has been pasted here :-)
> Ignoring that, the updated description for the "available" method looks okay
> but might be clearer to say that closeEntry has been called on the current
> entry.
whoops, fixed :-)
---
On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe wrote:
> unfortunately, your patch will make backporting more difficult. We cannot
> downport it to older releases compiled with older compilers. But since it
> touches a lot of files it will sit smack in the middle of patch sequences,
> requirin
On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes wrote:
>> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the
>> methods
>
> Wow I'm really having eyesight problems today! Sorry about that.
Haha, no worries
-
PR: https://git.openjdk.org/jdk/pull/11081
On Mon, 14 Nov 2022 08:01:27 GMT, David Holmes wrote:
>> I'm not sure I follow, I didn't remove anything here?
>
> Sorry my eyes must be playing tricks on me. ??
>
> Why did you need to add this here?
It's to avoid redefining the linkage as static in os_windows.cpp (where it's
implemented) aft
> Enhance the Java programming language with string templates, which are
> similar to string literals but contain embedded expressions. A string
> template is interpreted at run time by replacing each expression with the
> result of evaluating that expression, possibly after further validation a
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters wrote:
>> make/autoconf/flags-cflags.m4 line 632:
>>
>>> 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
>>> xclang; then
>>> 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections
>>> -fdata-sections \
>>> 632
On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs wrote:
> Process.waitFor() throws IllegalThreadStateException when a process returns
> an exit code of 259.
> As described in the bug report, `waitFor()` should not be sensitive to the
> exit value.
> Previously, it erroneously threw IllegalStateExc
On Sun, 13 Nov 2022 21:08:53 GMT, Claes Redestad wrote:
> Also, I'd like to note that C2 auto-vectorization support is not too far away
> from being able to optimize hash code computations. At some point, I was able
> to achieve some promising results with modest tweaking of SuperWord pass:
htt
> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
> code across the JDK can be replaced and simplified with cleaner language
> features that were previously not available due to required compatibili
> Enhance the Java programming language with string templates, which are
> similar to string literals but contain embedded expressions. A string
> template is interpreted at run time by replacing each expression with the
> result of evaluating that expression, possibly after further validation a
> Enhance the Java programming language with string templates, which are
> similar to string literals but contain embedded expressions. A string
> template is interpreted at run time by replacing each expression with the
> result of evaluating that expression, possibly after further validation a
> Enhance the Java programming language with string templates, which are
> similar to string literals but contain embedded expressions. A string
> template is interpreted at run time by replacing each expression with the
> result of evaluating that expression, possibly after further validation a
On Sun, 13 Nov 2022 21:01:21 GMT, Claes Redestad wrote:
>> src/hotspot/share/opto/intrinsicnode.hpp line 175:
>>
>>> 173: // as well as adjusting for special treatment of various encoding of
>>> String
>>> 174: // arrays. Must correspond to declared constants in
>>> jdk.internal.util.Array
On Fri, 4 Nov 2022 22:12:14 GMT, Markus KARG wrote:
> This PR implements JDK-8296431
This pull request has now been integrated.
Changeset: 95b84050
Author:Markus Karg
Committer: Brian Burkhalter
URL:
https://git.openjdk.org/jdk/commit/95b84050fc009b5665d20168d0470c9f31598d9a
Stats:
On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter wrote:
> On Windows, suppress failure if the total space indicated by `df` is less
> than `FileStore::getTotalSpace` and the free space indicated by `df` equals
> `FileStore::getUnallocatedSpace`.
This pull request has now been integrated.
Ch
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
On Mon, 14 Nov 2022 11:08:25 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 179:
>>
>>> 177: * {@link #closeEntry()} has been called, otherwise always return
>>> 1.
>>> 178: * I think it will need to say that input stream for the curre
On Sun, 13 Nov 2022 19:50:46 GMT, Claes Redestad wrote:
> ... several challenges were brought up to the table, including how to deal
> with all the different contingencies that might be the result of a safepoint,
> including deoptimization.
FTR if the intrinsic is represented as a stand-alone
On Sun, 13 Nov 2022 21:08:53 GMT, Claes Redestad wrote:
> How far off is this ...?
Back then it looked way too constrained (tight constraints on code shapes). But
I considered it as a generally applicable optimization.
> ... do you think it'll be able to match the efficiency we see here with
On Mon, 14 Nov 2022 18:16:50 GMT, Lance Andersen wrote:
>> Please review the following PR which updates several of the ZipInputStream
>> methods whose javadoc is inherited to clarify the methods are acting on
>> the current ZIP Entry.
>>
>> There are no changes in behavior. The main descrip
On Mon, 14 Nov 2022 19:48:43 GMT, Alan Bateman wrote:
> The updated wording looks okay. One small thing is that I think it would be a
> bit better if the word "always" were dropped.
Removed always and just pushed another commit with that change. Thank you for
the feedback
-
PR:
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
On Mon, 14 Nov 2022 20:03:24 GMT, Lance Andersen wrote:
>> Please review the following PR which updates several of the ZipInputStream
>> methods whose javadoc is inherited to clarify the methods are acting on
>> the current ZIP Entry.
>>
>> There are no changes in behavior. The main descrip
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
On Mon, 14 Nov 2022 21:00:16 GMT, Brian Burkhalter wrote:
> Nitpick: should the `InputStream` import precede that of `IOException`?
Gonna leave this as is as IntelliJ keeps changing it and not worth fighting
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 178:
>
>> 176:
On Mon, 14 Nov 2022 21:26:08 GMT, Lance Andersen wrote:
>> Please review the following PR which updates several of the ZipInputStream
>> methods whose javadoc is inherited to clarify the methods are acting on
>> the current ZIP Entry.
>>
>> There are no changes in behavior. The main descrip
On Thu, 10 Nov 2022 16:48:19 GMT, Jorn Vernee wrote:
>> Pull in linker implementation changes, that include non-trivial changes to
>> VM code, from the panama-foreign repo into the main JDK.
>>
>> This is split off from the main JEP integration to make reviewing easier.
>>
>> This includes the
On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert to using simpler solution similar to the original 8274980
>
> make/hotspot/lib/CompileJvm.gmk line 67:
>
>> 65:
As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329),
previously, the jar validator compare the "version" to validate a multi-release
jar. The "version" is a mix of the major and minor version fused into a single
int, which might be a negative number with `--enable-preview`
Can I please get a review of this change which proposes to fix
https://bugs.openjdk.org/browse/JDK-8292317?
The `java.util.Iterator` has a `forEachRemaining(Consumer action)`
method. As per its contract, the implementations are expected to throw a
`NullPointerException` if the passed `action` i
On Tue, 15 Nov 2022 02:10:01 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix
> https://bugs.openjdk.org/browse/JDK-8292317?
>
> The `java.util.Iterator` has a `forEachRemaining(Consumer action)`
> method. As per its contract, the implementations are ex
On Mon, 14 Nov 2022 21:26:08 GMT, Lance Andersen wrote:
>> Please review the following PR which updates several of the ZipInputStream
>> methods whose javadoc is inherited to clarify the methods are acting on
>> the current ZIP Entry.
>>
>> There are no changes in behavior. The main descrip
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters wrote:
>> make/hotspot/lib/CompileJvm.gmk line 67:
>>
>>> 65: # Hotspot cannot handle an empty build number
>>> 66: VERSION_BUILD := 0
>>> 67: endif
>>
>> I think the proposed "solution" is *much* worse than this.
>
> Reverted to use the origi
On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes wrote:
>> Yep, it was renamed since the file is also named VISCPP, and I felt that
>> matching the names was a good style change
>
> I think it is the file that has the "bad" name in this case. :( But okay.
I also think the macro name should be lef
42 matches
Mail list logo
