> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote:
>
>> On Jun 14, 2020, at 12:45 AM, Philip Race wrote:
>>
>> Kim,
>>
>>
>> Until it says in "the JDK" and not "in HotSpot" you have not addressed my
>> main point.
>> Please rename the JEP.
After some off-list discussions I have a better idea
On 6/17/20 7:34 PM, serguei.spit...@oracle.com wrote:
Hi Mandy,
This looks good from the Serviceability point of view.
> No change is made in JNI. JNI could be considered to disallow
modification of
> final fields in records and hidden classes (static and instance
fields).
> But JNI has
Hi Mandy,
This looks good from the Serviceability point of view.
> No change is made in JNI. JNI could be considered to disallow
modification of
> final fields in records and hidden classes (static and instance fields).
> But JNI has superpower and the current spec already allows to modify
>
Hi all,
I tried to build OpenJDK fastdebug with GCC 10.1 on Ubuntu 18.04, but I
saw some compiler warnings as follows:
In file included from
/home/jyukutyo/code/jdk/src/hotspot/share/classfile/systemDictionary.hpp:31,
from
/home/jyukutyo/code/jdk/src/hotspot/share/classfile/
Hi Chris,
AbstractMemorySegmentImpl
—
In vectorizedMismatchLarge:
163 if (remaining > 7)
164 throw new InternalError("remaining greater than 7: " +
remaining);
165 i = length - remaining;
166 }
Should this check be an assert?
—
This fix pro
Thanks! Pushed.
On Wed, Jun 17, 2020 at 12:37 PM wrote:
>
> Thanks, Martin. +1
>
> When you do the push, please update the copyright year to 2020.
>
> Naoto
>
> On 6/17/20 12:30 PM, Roger Riggs wrote:
> > Hi Martin,
> >
> > Looks fine,
> >
> > I'm embarrassed by the one in the java.time tests, we
Thanks! Submitted.
On Wed, Jun 17, 2020 at 12:14 PM Joe Darcy wrote:
>
> Looks good Martin; thanks for fixing,
>
> -Joe
>
> On 6/17/2020 11:44 AM, Martin Buchholz wrote:
> > 8247782: typos in java.math
> > https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
> > https://bugs.openjdk.jav
Thanks, Martin. +1
When you do the push, please update the copyright year to 2020.
Naoto
On 6/17/20 12:30 PM, Roger Riggs wrote:
Hi Martin,
Looks fine,
I'm embarrassed by the one in the java.time tests, we should have known
better.
Thanks, Roger
On 6/17/20 3:22 PM, Martin Buchholz wrote
Hi Martin,
Looks fine,
I'm embarrassed by the one in the java.time tests, we should have known
better.
Thanks, Roger
On 6/17/20 3:22 PM, Martin Buchholz wrote:
No actual bugs fixed, but good to stamp out all instances of new Date(1970)
8247706: Unintentional use of new Date(year...) with
No actual bugs fixed, but good to stamp out all instances of new Date(1970)
8247706: Unintentional use of new Date(year...) with absolute year
https://cr.openjdk.java.net/~martin/webrevs/jdk/Date-constructor-1900/
https://bugs.openjdk.java.net/browse/JDK-8247706
The "1990" below looks like a simp
Looks good Martin; thanks for fixing,
-Joe
On 6/17/2020 11:44 AM, Martin Buchholz wrote:
8247782: typos in java.math
https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
https://bugs.openjdk.java.net/browse/JDK-8247782
Looks fine. Please add the label noreg-doc to make the automatic verification
happy :-)
Best
Lance
> On Jun 17, 2020, at 2:44 PM, Martin Buchholz wrote:
>
> 8247782: typos in java.math
> https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
> https://bugs.openjdk.java.net/browse/JDK-
On 17/06/2020 16:38, Erik Joelsson wrote:
Ah, misunderstood you then. I added a comment to JDK-8213216 with more
details and shortened the comment in the test:
http://cr.openjdk.java.net/~erikj/8213214/webrev.03/
Looks okay as a workaround until we figure out what to do with subst.
-Alan.
Looks fine.
On 6/17/20 2:44 PM, Martin Buchholz wrote:
8247782: typos in java.math
https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
https://bugs.openjdk.java.net/browse/JDK-8247782
8247782: typos in java.math
https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
https://bugs.openjdk.java.net/browse/JDK-8247782
Hi Vladimir,
Thanks for the review and feedback.
FWIW. The spec of java.lang.reflect.AccessibleObject and Field
specifies which final fields can be modified or not. It use the
*non-modifiable* term and JVM can rely on.
I will keep the patch as is. I'm happy to clean this up when a more
d
On 6/17/20 8:11 AM, Aleksey Shipilev wrote:
On 6/15/20 11:58 PM, Mandy Chung wrote:
This patch also proposes `sun.misc.Unsafe::objectFieldOffset` and
`sun.misc.Unsafe::staticField{Offset/Base}` not to support records.
Note this would break otherwise innocuous introspection for records, for
Yeh, you are right. It was copy/paste error. Thank you for the correction!
- Alexey
On 6/16/2020 6:13 PM, Alexander Matveev wrote:
Hi Alexey,
Looks good. I think you got links and bug ID incorrect. It should be
JDK-8246244 and you have 8264244. Links also does not work. Working
links are:
h
The MemorySegment::mismatch implementation added vectorized mismatch of long
sizes. The implementation is trivial, but the starting point for a more
optimized implementation, if needed. ArraysSupport::vectorizedMismatchLarge
incorrectly returns the bitwise complement of the offset of the first m
On 2020-06-17 07:43, Alan Bateman wrote:
On 17/06/2020 14:47, Erik Joelsson wrote:
I've tried to make this clearer in the comment.
http://cr.openjdk.java.net/~erikj/8213214/webrev.02/
I would prefer if you could move the notes/comment from L125-157 to
the bug report to avoid cluttering the
On 6/15/20 11:58 PM, Mandy Chung wrote:
> This patch also proposes `sun.misc.Unsafe::objectFieldOffset` and
> `sun.misc.Unsafe::staticField{Offset/Base}` not to support records.
Note this would break otherwise innocuous introspection for records, for
example dumping the VM
layout with JOL:
htt
- Mail original -
> De: "Peter Levart"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "Chris Hegarty"
>
> Envoyé: Mercredi 17 Juin 2020 07:37:16
> Objet: Re: RFR: 8247532: Records deserialization is slow
> Hi Remi,
>
>
> The keys used are based on the ordered names and types of "fields" i
On 17/06/2020 14:47, Erik Joelsson wrote:
I've tried to make this clearer in the comment.
http://cr.openjdk.java.net/~erikj/8213214/webrev.02/
I would prefer if you could move the notes/comment from L125-157 to the
bug report to avoid cluttering the test. Instead, the test just needs a
one l
> On Jun 17, 2020, at 3:54 AM, Claes Redestad wrote:
>
> On 2020-06-16 18:06, Paul Sandoz wrote:
>> Looks good.
>
> Thanks!
>
>> It’s tempting to do something like this to de-dup the code with less
>> potential for mistakes:
>> String s = null;
>> // Select the singular non-null value, if a
Peter,
> On 17 Jun 2020, at 09:23, Chris Hegarty wrote:
>
>> On 17 Jun 2020, at 06:44, Peter Levart wrote:
..
>>> If there is a way for a test to compile several versions of the same
>>> (record) class and then produce byte streams with it, then we could
>>> simulate various class-evolut
On 2020-06-17 01:24, Alan Bateman wrote:
On 16/06/2020 18:44, Erik Joelsson wrote:
There are a lot of jtreg tests that use temporary files. These
temporary files add up over time and fill up the global temp
directories on our test systems. To tackle this, we should try to
redirect these temp
Hello Daniel,
Thank you for review.
As you suggested I’ve added static factory methods to create TlsChannelBinding
class and changed connectionTimeout verification to "if (connectTimeout <= 0)"
Also, I’ve added simple regression test to verify Channel Binding parameters.
Please find updated we
Looks good!
I welcome and fully support such hardening of final field handling for
new language features.
Minor comment on naming: "trusted final field" is an JVM implementation
detail and I'd prefer to keep it internal to JVM. (I hope it'll
eventually go away and will be replaced with a mor
On 2020-06-16 18:06, Paul Sandoz wrote:
Looks good.
Thanks!
It’s tempting to do something like this to de-dup the code with less potential
for mistakes:
String s = null;
// Select the singular non-null value, if any
If (s0 != null && s1 == null) s = s0;
else if (s0 == null && s1 != null) s
On 16/06/2020 18:44, Erik Joelsson wrote:
There are a lot of jtreg tests that use temporary files. These
temporary files add up over time and fill up the global temp
directories on our test systems. To tackle this, we should try to
redirect these temporary files into a directory controlled by t
> On 17 Jun 2020, at 06:44, Peter Levart wrote:
>>> ..
>> If there is a way for a test to compile several versions of the same
>> (record) class and then produce byte streams with it, then we could simulate
>> various class-evolution cases (field missing, surplus field, change of field
>> ty
On 6/17/20 8:08 AM, Peter Levart wrote:
On 6/16/20 5:15 PM, Chris Hegarty wrote:
The caching is on a per-stream-field shape basis, which should be
consistent in the common case, but of course is not always guaranteed
to be the case, hence the need for the cache. I think that this
should be
> On 17 Jun 2020, at 07:08, Peter Levart wrote:
>
>
> On 6/16/20 5:15 PM, Chris Hegarty wrote:
>> The caching is on a per-stream-field shape basis, which should be consistent
>> in the common case, but of course is not always guaranteed to be the case,
>> hence the need for the cache. I thi
33 matches
Mail list logo
