> …tation
Mitsuru kariya has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3522/files
- new: https://git.openjdk.java.net/jdk/pull/3522/files/5f671f95..d1e30f
On Wed, 28 Apr 2021 22:22:38 GMT, Chris Plummer wrote:
> Please update all copyright dates to 2021.
Thank you for your advice.
I just updated the copyright.
-
PR: https://git.openjdk.java.net/jdk/pull/3522
On Wed, 28 Apr 2021 09:41:14 GMT, Albert Mingkun Yang wrote:
>> 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 req
On Wed, 28 Apr 2021 22:23:17 GMT, Chris Plummer wrote:
> Also, please give a proper description of the PR. Right now it just says
> "…tation"
Oh, I'm embarrassed to say that I completely overlooked this.
I just updated the description.
-
PR: https://git.openjdk.java.net/jdk/pull/3
On Thu, 29 Apr 2021 04:41:20 GMT, Chris Plummer wrote:
> Please enable github actions on your jdk personal fork to enable the
> pre-submit testing.
I've changed the settings.
-
PR: https://git.openjdk.java.net/jdk/pull/3522
> 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.classesByName("") is expecting the fully qualified name example
> "java
On Thu, 29 Apr 2021 04:31:35 GMT, Chris Plummer wrote:
>> Hi Chris,
>>
>> Thanks for looking into this,
>>
>>>Do we even need findComponentType() any more? Isn't
>>>ReferenceTypeImpl.findType() sufficient.
>>
>> We still need findComponentType(),
>> Difference between findType() and findCo
> It has some cascading effect; two performance variables, `fastWaste` and
> `maxFastWaste`, can be removed also.
Albert Mingkun Yang has updated the pull request incrementally with one
additional commit since the last revision:
review
-
Changes:
- all: https://git.openjdk.jav
On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote:
>> It has some cascading effect; two performance variables, `fastWaste` and
>> `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revisio
On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote:
>> It has some cascading effect; two performance variables, `fastWaste` and
>> `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revisio
On Thu, 29 Apr 2021 08:46:57 GMT, Per Liden wrote:
> Maybe this could be a follow up refinement?
Sure, will do so after this PR.
-
PR: https://git.openjdk.java.net/jdk/pull/3756
On Thu, 29 Apr 2021 07:05:18 GMT, Mitsuru kariya
wrote:
>> The current `hashCode` implementation of SA's Address subclasses ignores the
>> upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one a
On Thu, 29 Apr 2021 10:36:59 GMT, Kevin Walls wrote:
> If you have time, these could all use the same change?
I have enough time to change them.
May I mix that fix into this pull request?
-
PR: https://git.openjdk.java.net/jdk/pull/3522
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
14 matches
Mail list logo
