On Thu, 15 Apr 2021 15:44:15 GMT, Mitsuru kariya
wrote:
> …tation
@kariya-mitsuru Please enable github actions on your jdk personal fork to
enable the pre-submit testing. Start with the following link:
https://github.com/kariya-mitsuru/jdk/actions
Click on "Settings" tab and then click on "A
On Wed, 28 Apr 2021 07:57:03 GMT, Fairoz Matte wrote:
> > Do we even need findComponentType() any more? Isn't
> > ReferenceTypeImpl.findType() sufficient.
>
> We still need findComponentType(),
> Difference between findType() and findComponentType() is that,
> findComponentType() tries to get
On Wed, 28 Apr 2021 12:17:18 GMT, Kevin Walls wrote:
> Hi,
> I didn't find it immediately obvious that this was safe, but I followed
> things and think that it is correct:
>
> The malloc'd pointer gets passed to...
> JvmtiEnv::AddToBootstrapClassLoaderSearch(const char* segment) {
>
> which ca
On Thu, 15 Apr 2021 15:44:15 GMT, Mitsuru kariya
wrote:
> …tation
Please update all copyright dates to 2021. Only the latest year need to be
updated. For example:
` * Copyright (c) 2002, 2013, Oracle and/or its affiliates. All rights
reserved.`
becomes
` * Copyright (c) 2002, 2021, Or
On Wed, 28 Apr 2021 21:48:15 GMT, Alex Menkov wrote:
>> Class loading may cause loading of some other system/internal classes (for
>> example loading of java.util.concurrent classes when an other thread loads
>> some classes concurrently).
>> The fix updates ClassPrepare test so it skip events
On Wed, 28 Apr 2021 20:47:29 GMT, David Holmes wrote:
>
> otherTread -> otherThread ?
>
fixed
-
PR: https://git.openjdk.java.net/jdk/pull/3732
> Class loading may cause loading of some other system/internal classes (for
> example loading of java.util.concurrent classes when an other thread loads
> some classes concurrently).
> The fix updates ClassPrepare test so it skip events for "unexpected" classes.
> Also it adds a testcase to veri
On 29/04/2021 5:21 am, Alex Menkov wrote:
On Tue, 27 Apr 2021 23:15:35 GMT, Chris Plummer wrote:
I don't see any mention in the CR of the test failing due to this issue. How
was it discovered? How is the fix being verified?
I discovered it researching JCK failure on a platform with UsageTra
> Class loading may cause loading of some other system/internal classes (for
> example loading of java.util.concurrent classes when an other thread loads
> some classes concurrently).
> The fix updates ClassPrepare test so it skip events for "unexpected" classes.
> Also it adds a testcase to veri
On Tue, 27 Apr 2021 23:12:36 GMT, Chris Plummer wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated comment
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassPrepare/classprep001/classprep001.cpp
> line 65:
>
>
On Tue, 27 Apr 2021 23:15:35 GMT, Chris Plummer wrote:
> I don't see any mention in the CR of the test failing due to this issue. How
> was it discovered? How is the fix being verified?
I discovered it researching JCK failure on a platform with UsageTracker enabled.
JCK test does exactly the sa
…tation
-
Commit messages:
- 8264734: SA's Address subclasses could use better hashCode() implementation
Changes: https://git.openjdk.java.net/jdk/pull/3522/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3522&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8
On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty
wrote:
> The synopsis pretty much says it all. There's a more detailed history in the
> RFE itself.
>
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 ser
On Wed, 28 Apr 2021 06:38:57 GMT, Wang Huang wrote:
> Dear All,
> I find a memory leak in `appendBootClassPath()`
> https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950
> * we malloc `resolved` fr
On Wed, 28 Apr 2021 06:38:57 GMT, Wang Huang wrote:
> Dear All,
> I find a memory leak in `appendBootClassPath()`
> https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950
> * we malloc `resolved` fr
> It has some cascading effect; two performance variables, `fastWaste` and
> `maxFastWaste`, can be removed also.
Albert Mingkun Yang has updated the pull request with a new target base due to
a merge or a rebase. The pull request now contains two commits:
- merge
- refill
-
Cha
It has some cascading effect; two performance variables, `fastWaste` and
`maxFastWaste`, can be removed also.
-
Commit messages:
- refill
Changes: https://git.openjdk.java.net/jdk/pull/3756/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=00
Issue: https://
On Tue, 27 Apr 2021 23:47:26 GMT, Chris Plummer wrote:
>> findComponentType() logic is wrong. In findComponentType() method, We always
>> get vm.classesByName() retruns empty list
>> list = vm.classesByName(parser.typeName());
>> We have "parser.typeName()" retruns " double[][]"
>> vm.classesByN
18 matches
Mail list logo
