On Tue, 12 Apr 2022 13:02:44 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/BufferedReader.java line 101:
>>
>>> 99: */
>>> 100: public BufferedReader(Reader in, int sz) {
>>> 101: Objects.requireNonNull(in);
>>
>> Not sure if that even matters - but there will
On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs wrote:
>>> Not sure if that even matters - but there will be a slight change of
>>> behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`.
>>> Instead of synchronizing on `in`, the `BufferedReader` will synchronize on
>>> `this`.
On Tue, 12 Apr 2022 19:09:32 GMT, Daniel Jeliński wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Tue, 12 Apr 2022 16:49:41 GMT, Daniel Jeliński wrote:
> If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies
> no waiting in Net.poll
It's benign for the current usages but you are right, it was not intentional.
-
PR: https://git.openjdk.java.net/jdk/pu
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
> JDK version to target.
>
> We will refresh this PR periodically to pick up changes and fixes from the
> loom repo.
>
> Most of the new mechanisms in the HotSpot VM are disabled by default and
> require running with
On Wed, 13 Apr 2022 11:35:33 GMT, ExE Boss wrote:
> Actually, we can’t in case `InternalLock.CAN_USE_INTERNAL_LOCK` is ever
> `false`
That's right, both StreamEncoder and StreamDecoder need the both cases.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss wrote:
>> Thanks - the same issue appears with `BufferedWriter`/`Writer`.
>
> The solution is to add the `private` constructor:
>
> private Reader(Object fallbackLock, Void internal) {
> // assert fallbackLock != null;
>
Move the AsyncGetCallTrace method implementation into a separate method and
wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
like it is done in
[JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jf
On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger
wrote:
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd2
On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger
wrote:
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd2
On Wed, 13 Apr 2022 15:11:41 GMT, Jaroslav Bachorik
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9c
On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger
wrote:
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd2
On Wed, 13 Apr 2022 15:19:43 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/prims/forte.cpp line 671:
>>
>>> 669: #ifndef ASSERT
>>> 670: trace->num_frames = ticks_unknown_state;
>>> 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext);
>>
>> ~Isn't [this
>> assert](https://github.com
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sam
On Wed, 13 Apr 2022 15:18:15 GMT, Thomas Stuefe wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Check for Thread::current_or_null_safe and other stuff
>
> src/hotspot/share/prims/forte.cpp line 674:
>
>> 67
On Wed, 13 Apr 2022 15:36:05 GMT, Johannes Bechberger
wrote:
>> src/hotspot/share/prims/forte.cpp line 674:
>>
>>> 672: os::ThreadCrashProtection crash_protection;
>>> 673: if (!crash_protection.call(cb)) {
>>> 674: if (trace->num_frames < -10 || trace->num_frames >= 0) {
>>
>> Where d
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sam
On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29ae
On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote:
> I dislike having different behavior between debug and release, I prefer to
> test what later runs in the field. Also, if we prevent crashes because we
> want to ignore them, we should ignore them in debug too, otherwise, we burn
> error
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sam
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d
On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote:
> Let's take advantage of Java 7 language feature - "Catching Multiple
> Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try'
> statement
This pull request ha
Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`,
`Unexpeted`, etc.
-
Commit messages:
- [PATCH] Fix 'expected' typo
- [PATCH] Fix 'expected' typo
- [PATCH] Fix 'expected' typo
Changes: https://git.openjdk.java.net/jdk/pull/8231/files
Webrev: https:/
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote:
> Found various typos of expected: `exepected`, `exept`, `epectedly`,
> `expeced`, `Unexpeted`, etc.
Expect the Unexpeted.
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8231
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote:
> Found various typos of expected: `exepected`, `exept`, `epectedly`,
> `expeced`, `Unexpeted`, etc.
test/jdk/java/lang/StackWalker/StackStreamTest.java line 218:
> 216: private static void equalsOrThrow(String label, List list,
>
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d
On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d
29 matches
Mail list logo
