On Sun, 10 Apr 2022 00:40:02 GMT, ExE Boss wrote:
> This is supposed to point to the `package‑summary.html`
Thanks, this link is indeed wrong. Will be fixed when we refresh.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
On Sun, 10 Apr 2022 22:14:41 GMT, Magnus Ihse Bursie wrote:
> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe
> there's a test missing that could have discovered this...)
The exception is in an incubator module, it's just that code in java.base can't
statically refere
On Mon, 11 Apr 2022 07:33:20 GMT, ExE Boss wrote:
> Maybe it should use a `MethodHandle` fetched using `IMPL_LOOKUP` instead, in
> order to avoid the runtime overhead of going through `CallerSensitive`
> methods (`Class.forName` and `Constructor.newInstance`).
>
> It should probably also be ca
On Mon, 11 Apr 2022 07:12:09 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java
>> line 81:
>>
>>> 79: Constructor ctor;
>>> 80: try {
>>> 81: Class exClass =
>>> Class.forName("jdk.incubator.concurrent.Struct
On Mon, 11 Apr 2022 06:41:54 GMT, Alan Bateman wrote:
>> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
>> with CNFE like "java.lang.NoClassDefFoundError:
>> jdk/test/lib/compiler/InMemoryJavaCompiler"
>>
>> It is not a loom specific bug, it might happen in jdk/jdk a
On Mon, 11 Apr 2022 06:41:54 GMT, Alan Bateman wrote:
>> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
>> with CNFE like "java.lang.NoClassDefFoundError:
>> jdk/test/lib/compiler/InMemoryJavaCompiler"
>>
>> It is not a loom specific bug, it might happen in jdk/jdk a
> JVMTI heap walking marks objects in order to track which have been visited
> already. In order to do that, it uses bits in the object header. Those are
> the same bits that are also used by some GCs to mark objects (the lowest two
> bits, also used by locking code). Some GCs also use the bits
On Sat, 9 Apr 2022 06:41:11 GMT, Thomas Stuefe wrote:
>>> On Apr 9\, 2022\, at 2\:44 AM\, Thomas Stuefe \>> openjdk\.java\.net> wrote\:
>>>
>>> On Fri\, 8 Apr 2022 17\:34\:57 GMT\, Roman Kennke \>> openjdk\.org> wrote\:
>>>
Yes\, I get that\. But the fragments and fragment\-table are thems
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
-
Commit messages:
- [PATCH] Collapse identical catch branches in java.mana
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> b
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> b
On Wed, 20 Oct 2021 09:36:38 GMT, Leo Korinth wrote:
>> The basic problem is that we are relying on undefined behaviour, as
>> documented in the code:
>>
>> // This whole business of passing information from ResourceObj::operator new
>> // to the ResourceObj constructor via fields in the "objec
On Fri, 25 Mar 2022 20:10:32 GMT, Roman Kennke wrote:
> JVMTI heap walking marks objects in order to track which have been visited
> already. In order to do that, it uses bits in the object header. Those are
> the same bits that are also used by some GCs to mark objects (the lowest two
> bits,
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> b
On Mon, 11 Apr 2022 16:21:34 GMT, Iris Clark wrote:
>> A trivial copyright fix to solve validate-source failure after JDK-8283710.
>
> Marked as reviewed by iris (Reviewer).
@irisclark - Thanks for the lightning fast review!
-
PR: https://git.openjdk.java.net/jdk/pull/8181
On Mon, 11 Apr 2022 16:20:02 GMT, Daniel D. Daugherty
wrote:
> A trivial copyright fix to solve validate-source failure after JDK-8283710.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/8181
A trivial copyright fix to solve validate-source failure after JDK-8283710.
-
Commit messages:
- 8284687: validate-source failure after JDK-8283710
Changes: https://git.openjdk.java.net/jdk/pull/8181/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8181&range=00
Issue:
On Mon, 11 Apr 2022 16:20:02 GMT, Daniel D. Daugherty
wrote:
> A trivial copyright fix to solve validate-source failure after JDK-8283710.
This pull request has now been integrated.
Changeset: 470a6684
Author:Daniel D. Daugherty
URL:
https://git.openjdk.java.net/jdk/commit/470a6684
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman 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 the HotSpot
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Sat, 9 Apr 2022 00:39:46 GMT, Alex Menkov wrote:
>> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
>> with CNFE like "java.lang.NoClassDefFoundError:
>> jdk/test/lib/compiler/InMemoryJavaCompiler"
>>
>> It is not a loom specific bug, it might happen in jdk/jdk als
On Mon, 11 Apr 2022 13:50:49 GMT, Leo Korinth wrote:
>> Leo Korinth has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review updates
>
> I would like to have this change approved, or the approval of removing
> tracking the allocation type
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>> b
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
Marked as reviewed b
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
Nice cleanup! Great
On Tue, 12 Apr 2022 00:12:42 GMT, Chris Plummer 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
>
> src/java.mana
Hello,
> new RuntimeException(exc1.getMessage())
I typically try to avoid swallowing the cause and especially the exception type
of a inner exception, especially in this case where two different exceptions
are caught. Better do tostring() and/or specify the exception as a cause to
have chainin
On Mon, 11 Apr 2022 07:52:34 GMT, Alan Bateman wrote:
> > @AlanBateman adding the explicit compile commands to add `--enable-preview`
> > is exactly what causes the problem. By compiling that individual file first
> > it also compiled some testlib dependencies but puts the classes in a
> > dif
On Mon, 11 Apr 2022 23:41:40 GMT, David Holmes wrote:
> This is wrong - it should be BITSET not BITMAP
Oh, good find! I filed a follow-up issue:
https://bugs.openjdk.java.net/browse/JDK-8284725
-
PR: https://git.openjdk.java.net/jdk/pull/7964
29 matches
Mail list logo
