On Tue, 13 Oct 2020 06:46:27 GMT, Ioi Lam wrote:
>> **Problem:** when iterating over the cloned vtables, the original code
>> assumes that they are laid out consecutively in
>> memory. However, since
>> [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory
>> allocated
> **Problem:** when iterating over the cloned vtables, the original code
> assumes that they are laid out consecutively in
> memory. However, since
> [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory
> allocated for each
> of the the cloned vtables is now 8-byte ali
On Tue, 13 Oct 2020 06:08:11 GMT, Aleksey Shipilev wrote:
> > I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit
> > flaky. Even if I disable CDS, sometime I
> > get failures in (non-CDS) test cases like `There cannot be a
> > NullPointerException at bci 14 of method by
On Tue, 13 Oct 2020 06:03:20 GMT, Ioi Lam wrote:
> I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit
> flaky. Even if I disable CDS, sometime I
> get failures in (non-CDS) test cases like `There cannot be a
> NullPointerException at bci 14 of method byte
> java.lang.St
On Mon, 12 Oct 2020 17:50:31 GMT, Aleksey Shipilev wrote:
> This looks reasonable to me, but after testing it on x86_32, I wonder if
> https://bugs.openjdk.java.net/browse/JDK-8254606 is the problem with this
> patch, or a different issue.
[JDK-8254606](https://bugs.openjdk.java.net/browse/JDK-
> **Problem:** when iterating over the cloned vtables, the original code
> assumes that they are laid out consecutively in
> memory. However, since
> [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory
> allocated for each
> of the the cloned vtables is now 8-byte ali
On Sun, 11 Oct 2020 22:21:28 GMT, Ioi Lam wrote:
> This PR changes declarations in jvmti.h like the following from
>
> struct _jvmtiTimerInfo;
> typedef struct _jvmtiTimerInfo jvmtiTimerInfo;
>
> to
>
> struct jvmtiTimerInfo;
> typedef struct jvmtiTimerInfo jvmtiTimerInfo;
>
> This way, it be
On Mon, 12 Oct 2020 23:11:33 GMT, Alex Menkov wrote:
>> Please review a trivial fix for JdwpAttachTest
>
> Alex Menkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> updated log/error messages accordingly Chris' suggestion
Hi Alex,
It loo
> Please review a trivial fix for JdwpAttachTest
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
updated log/error messages accordingly Chris' suggestion
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/619/files
On Mon, 12 Oct 2020 21:39:05 GMT, Chris Plummer wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated log/error messages accordingly Chris' suggestion
>
> I think you got this backward. `expectedResult` indicates
On Mon, 12 Oct 2020 21:03:55 GMT, Alex Menkov wrote:
> Please review a trivial fix for JdwpAttachTest
I think you got this backward. `expectedResult` indicates whether or not a
successful attach was expected. Since we are
not in the exception handling part of the code here, that means it did su
> 8246774: implementing Record Classes as a standard feature in Java
Vicente Romero has updated the pull request with a new target base due to a
merge or a rebase. The pull request now
contains ten commits:
- Merge branch 'master' into JDK-8246774
- removing unused jcod file
- remove unnecess
Please review a trivial fix for JdwpAttachTest
-
Commit messages:
- 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly
Changes: https://git.openjdk.java.net/jdk/pull/619/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=619&range=00
Issue: https://bugs.o
On Sun, 11 Oct 2020 04:04:56 GMT, Ioi Lam wrote:
> **Problem:** when iterating over the cloned vtables, the original code
> assumes that they are laid out consecutively in
> memory. However, since
> [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory
> allocated for e
Test only change. With
[JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been
added on the
hotspot side, but nothing for the Java Metrics code. Same for
[JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This patch
alleviates that.
Thoughts?
-
On Thu, 1 Oct 2020 15:02:01 GMT, Vladimir Kempik wrote:
> Please review this change for hotspot and one test.
> There is few JVMTI callback/event functions in jdk which signature doesn't
> match specification.
> for example:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env
On Mon, 12 Oct 2020 12:07:23 GMT, Vladimir Kempik wrote:
>> Please review this change for hotspot and one test.
>> There is few JVMTI callback/event functions in jdk which signature doesn't
>> match specification.
>> for example:
>> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEn
On Mon, 5 Oct 2020 12:44:34 GMT, Vladimir Kempik wrote:
>>> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
>>> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_
>>> Hi Vladimir,
>>>
>>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote:
>>>
>>> > On Fri, 2 Oct 2020 07
> Please review this change for hotspot and one test.
> There is few JVMTI callback/event functions in jdk which signature doesn't
> match specification.
> for example:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env,
> jboolean* enabled, ...)
> but according to jvmti spec
19 matches
Mail list logo
