On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote:
>> When using -Xcomp, the liveness of some objects the test allocates is more
>> precisely known, allowing the objects to be collected before the test
>> expects. This became an issue in the loom repo because it has changes that
>> result
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote:
>> When using -Xcomp, the liveness of some objects the test allocates is more
>> precisely known, allowing the objects to be collected before the test
>> expects. This became an issue in the loom repo because it has changes that
>> result
We observe a native memory leak when repeating JDI operations from Eclipse in a
debuggee JVM. See bug report for details.
AFAICT, this happens because we override methodSignature of a possible
pre-existing request object. I am not sure if there is a better place to
deallocate the signature.
Al
The test is failing to find certain types in the scanoops output when run with
-Xcomp. This is happening in the loom repo. The reason it is happening there is
because loom introduced a full GC during codecache sweeping. The test only runs
scanoops on the eden gen, and the full GC is causing obje
On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote:
>> When using -Xcomp, the liveness of some objects the test allocates is more
>> precisely known, allowing the objects to be collected before the test
>> expects. This became an issue in the loom repo because it has changes that
>> result
On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote:
> The test does a "threadcontext -v -a", and from the following output
> determines the threadID of the SteadyStateThread:
>
> `Thread "SteadyStateThread" id=23 Address=0x01dc51749420`
>
> It then tries threadcontext on this id, but
On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote:
> The test does a "threadcontext -v -a", and from the following output
> determines the threadID of the SteadyStateThread:
>
> `Thread "SteadyStateThread" id=23 Address=0x01dc51749420`
>
> It then tries threadcontext on this id, but
On Wed, 26 Jan 2022 22:50:47 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Guard against invalid CodeBlobs that may throw exceptions.
>
> Looks okay to me.
> Thanks,
> Serguei
@sspitsyn Can
On Fri, 28 Jan 2022 04:27:18 GMT, Chris Plummer wrote:
> When using -Xcomp, the liveness of some objects the test allocates is more
> precisely known, allowing the objects to be collected before the test
> expects. This became an issue in the loom repo because it has changes that
> result in a
While looking into guts of javadoc comment inheritance, I noticed that a number
of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I
believe that the real target should be "8.4.8. Inheritance, Overriding, an
On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote:
> While looking into guts of javadoc comment inheritance, I noticed that a
> number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I
> believe th
On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote:
> While looking into guts of javadoc comment inheritance, I noticed that a
> number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I
> believe th
On Tue, 1 Feb 2022 14:44:43 GMT, Roman Kennke wrote:
> We observe a native memory leak when repeating JDI operations from Eclipse in
> a debuggee JVM. See bug report for details.
>
> AFAICT, this happens because we override methodSignature of a possible
> pre-existing request object. I am not
On Tue, 1 Feb 2022 19:26:19 GMT, Chris Plummer wrote:
> Shouldn't this be done when the invoke has completed rather than at the start
> of the next invoke? Otherwise you potentially have one outstanding allocation
> for every thread, and you still have a leak when the thread exits.
Yes, perhap
On Tue, 1 Feb 2022 19:33:22 GMT, Roman Kennke wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 240:
>>
>>> 238: }
>>> 239: error = methodSignature(method, NULL, &request->methodSignature,
>>> NULL);
>>> 240: if (error != JVMTI_ERROR_NONE) {
>>
>> Shouldn't this be
On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote:
>> It's possible for an address to be in the codecache but not in any CodeBlob.
>> Don't assert in this case.
>>
>> Also I ran into a couple of other asserts listed below. It looks like since
>> dumping the threadcontext can result in usin
On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote:
>> It's possible for an address to be in the codecache but not in any CodeBlob.
>> Don't assert in this case.
>>
>> Also I ran into a couple of other asserts listed below. It looks like since
>> dumping the threadcontext can result in usin
On Tue, 25 Jan 2022 22:07:37 GMT, Chris Plummer wrote:
> It's possible for an address to be in the codecache but not in any CodeBlob.
> Don't assert in this case.
>
> Also I ran into a couple of other asserts listed below. It looks like since
> dumping the threadcontext can result in using Poi
On Thu, 27 Jan 2022 11:32:18 GMT, Alex Menkov wrote:
>> Changes:
>> - ClassFileReconstituter is updated to restore "MethodParameters" attribute;
>> - handling of the attribute in VM_RedefineClasses is moved to be consistent
>> with other code (like local variable table);
>> - copied ClassTransfo
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
On Wed, 2 Feb 2022 00:14:06 GMT, Serguei Spitsyn wrote:
> There is minor duplication but it is okay as there is no good way to get rid
> of it.
I considered a loop or common method, but it seemed not to be worth it and
likely less readable.
-
PR: https://git.openjdk.java.net/jdk/
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
22 matches
Mail list logo
