Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot() [v2]

[Xiaohong Gong]

On Wed, 31 Mar 2021 16:42:09 GMT, Paul Sandoz  wrote:

> Would you mind updating the existing `AbstractMask.andNot` implementation? 
> rather than changing `VectorMask.andNot`. That fits in with the current 
> implementation pattern.

Hi @PaulSandoz , thanks for looking at this PR. I'v updated the patch according 
to your comments. Would you mind having look at it again? Thanks so much!

-

PR: https://git.openjdk.java.net/jdk/pull/3211

Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot() [v2]

[Xiaohong Gong]

> Currently "VectorMask.andNot()" is not vectorized:
> public VectorMask andNot(VectorMask m) {
> // FIXME: Generate good code here.
> return bOp(m, (i, a, b) -> a && !b);
> }
> This can be implemented with` "and(m.not())" `directly. Since 
> `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
> boolean[] mask = fm.apply(SPECIES.length());
> boolean[] r = fmt.apply(SPECIES.length());
> VectorMask rm = VectorMask.fromArray(SPECIES, r, 0);
> 
> for (int ic = 0; ic < INVOC_COUNT; ic++) {
>   for (int i = 0; i < mask.length; i += SPECIES.length()) {
> VectorMask vmask = VectorMask.fromArray(SPECIES, mask, i);
>   rm = rm.andNot(vmask);
> }
> }
> return rm;
>   }

Xiaohong Gong has updated the pull request incrementally with one additional 
commit since the last revision:

  Move the changing to AbstractMask.andNot and revert changes in VectorMask
  
  Change-Id: Ie3ec8f53cb24526c8e1ccc68038355d024910818
  CustomizedGitHooks: yes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3211/files
  - new: https://git.openjdk.java.net/jdk/pull/3211/files/ccb73d92..33ac041e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3211=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3211=00-01

  Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3211.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3211/head:pull/3211

PR: https://git.openjdk.java.net/jdk/pull/3211

Re: RFR: 8037397: Lost nested character class after intersection &

[Florent Guillaume]

On Wed, 31 Mar 2021 20:38:33 GMT, Ian Graves  wrote:

> Bug fix with the intersection `&&` operator in regex patterns. In 
> JDK-8037397, some character classes on the right hand side of the operator 
> are dropped in cases where nested `[..]` classes are used with non "nested" 
> ones.

src/java.base/share/classes/java/util/regex/Pattern.java line 2666:

> 2664: } else { // abc&
> 2665: unread();
> 2666: if(right == null) {

Missing space after `if`. There will be a unit test as well?

(Please tell me if these comments aren't suitable or relevant, as I'm not 
involved in the project.)

-

PR: https://git.openjdk.java.net/jdk/pull/3291

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Dan Smith]

> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore 
>  wrote:
> 
> What I'd be curious though, is if the @ValueBased annotation could be 
> enhanced to say _which_ primitive class default you want (and then javac 
> could enforce extra checks if you pick the "val" default). If something like 
> this was feasible (cc'ing Dan), maybe some of the friction here could be 
> removed?

You mean annotate a class with "pretend this class's name represents a value 
type" and then implement the associated null checks in javac, even though we 
don't actually have value types yet?

I'd expect that to run into a number of problems related to the fact that the 
language model hasn't actually been updated to include primitive classes or 
value types yet. Plus the lack of features like reference types (Foo.ref) would 
be limiting for programmers who need them. Plus binary incompatibility—value 
types need special encoding in class files, and those class files aren't legal 
yet; when they are, you risk mismatches.

In this case I think the straightforward approach of just completing and 
delivering the Valhalla features is better than trying to spin off a small 
taste of them early.

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

[Joe Darcy]

The IEEE decimal floating-point is usable for currency calculations, but 
it is not intended to be limited to such calculations. A type targeted 
at currency calculations would focus more on fixed-point rounding, 
rounding to a given digit position (scale in BigDecimal terminology), as 
opposed to floating-point rounding which is primarily rounding to a 
fixed precision. In a currency setting, rounding to a given scale would 
mean rounding to whole dollars (pounds, euros, etc.), cents, mills, or 
other particular fractional quantity.


-Joe

On 3/31/2021 2:24 PM, Douglas Surber wrote:

My understanding is that IEEE decimal floating point is intended for currency. 
A large fraction of numeric values stored in databases are currency. It's not 
obvious to me why an e-commerce web site would not want to use Decimal128 to 
represent prices, extensions, taxes, discounts, totals, etc.


On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti 
 wrote:

Hi Douglas,

yes, different vendors have different limits on the precision, the most extreme 
probably being PostgreSQL.

But apart from that, the arithmetic is different.

A better option is to implement some optimized fixed precision classes like 
SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. But, as 
I mentioned, this is something different than Decimal.


Greetings
Raffaello



On 2021-03-31 22:53, Douglas Surber wrote:

Understood. The problem is that right now the only appropriate type for 
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of 
users avoid it.
Decimal128 supports 34 significant digits. The max precision of SQL numeric 
types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. 
So there are a huge range of values representable in SQL that are not 
representable in Decimal128. BUT, for the vast majority of applications that 
might be tempted to use Decimal128, those non-representable numbers don't 
occur. Currency amounts exceeding 34 decimal digits of precision are an almost 
non-existent minority.
Very few apps will pay the price of using BigDecimal even though it would 
support huge numbers exactly. Instead they find workarounds that are more 
efficient. Decimal128 would be a substantial improvement for those apps.
Douglas

On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti 
 wrote:

Hi,

I think there's a misunderstanding about the nature of IEEE 754 Decimal 
(e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).

SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall 
maximum precision p and a scale s, the number of digits to the right of the 
decimal point (both parameters can be selected freely inside some ranges). For 
example, DECIMAL(2, 1) can represent only the values
-9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.

IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of 
precision 2 can represent values of the form c*10^q, where integer c meets |c| 
< 100 (that is, max two digits) and integer q is limited in some range. It 
covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 
(=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded 
to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the 
same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
But really, the position of the decimal point is floating.

IEEE decimals and SQL decimals are fundamentally different and ave different 
arithmetic, so I wouldn't recommend using the proposed classes for JDBC.

On the positive side, SQL decimals, are easier to implement if the maximum 
allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.


Greetings
Raffaello

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

The issue is to simulate SQL DECIMAL arithmetic using IEEE Decimal

Consider the division 20 / 3. Using Decimal64:
20 / 3 -> 6.7
Using DECIMAL(38, 6), or many other reasonable combinations:
20 / 3 -> 6.67

We could expose a richer API in Decimal, similar to BigDecimal's. It 
is doable, but beyond IEEE and my current plan.


In addition, I find that the point issued by Maurizio about the best 
name for the Valhalla primitive class is important enough for the 
community at large to warrant a rumination pause.


Let me ponder about how to enrich the API to support SQL for a couple of 
days or so. In the meantime, the Valhalla guys may come up with a good 
solution to better assist migration of @ValueBased classes to truly 
primitive classes without disrupting existing code that depends on them, 
as described by Maurizio in his previous post.




On 2021-03-31 23:24, Douglas Surber wrote:

My understanding is that IEEE decimal floating point is intended for currency. 
A large fraction of numeric values stored in databases are currency. It's not 
obvious to me why an e-commerce web site would not want to use Decimal128 to 
represent prices, extensions, taxes, discounts, totals, etc.


On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti 
 wrote:

Hi Douglas,

yes, different vendors have different limits on the precision, the most extreme 
probably being PostgreSQL.

But apart from that, the arithmetic is different.

A better option is to implement some optimized fixed precision classes like 
SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. But, as 
I mentioned, this is something different than Decimal.


Greetings
Raffaello



On 2021-03-31 22:53, Douglas Surber wrote:

Understood. The problem is that right now the only appropriate type for 
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of 
users avoid it.
Decimal128 supports 34 significant digits. The max precision of SQL numeric 
types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. 
So there are a huge range of values representable in SQL that are not 
representable in Decimal128. BUT, for the vast majority of applications that 
might be tempted to use Decimal128, those non-representable numbers don't 
occur. Currency amounts exceeding 34 decimal digits of precision are an almost 
non-existent minority.
Very few apps will pay the price of using BigDecimal even though it would 
support huge numbers exactly. Instead they find workarounds that are more 
efficient. Decimal128 would be a substantial improvement for those apps.
Douglas

On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti 
 wrote:

Hi,

I think there's a misunderstanding about the nature of IEEE 754 Decimal 
(e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).

SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall 
maximum precision p and a scale s, the number of digits to the right of the 
decimal point (both parameters can be selected freely inside some ranges). For 
example, DECIMAL(2, 1) can represent only the values
-9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.

IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of 
precision 2 can represent values of the form c*10^q, where integer c meets |c| 
< 100 (that is, max two digits) and integer q is limited in some range. It 
covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 
(=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded 
to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the 
same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
But really, the position of the decimal point is floating.

IEEE decimals and SQL decimals are fundamentally different and ave different 
arithmetic, so I wouldn't recommend using the proposed classes for JDBC.

On the positive side, SQL decimals, are easier to implement if the maximum 
allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.


Greetings
Raffaello

Re: RFR: JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching

[Alexey Semenyuk]

On Wed, 31 Mar 2021 19:30:10 GMT, Andy Herrick  wrote:

> Deriving the cfg file name is broken on mac and linux when the application 
> name has a "." in it.

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/native/common/FileUtils.h line 76:

> 74: 
> 75: // extract the name from the launcher path
> 76: tstring extractName(const tstring& path);

Function name seems to be misleading. 
If it specifically designed to be applied to executables, I'd name it 
`stripExecutableSuffix()`. On Unix implementation would return passed in string 
as is without calling `basename()` and on Windows would just strip ".exe" 
suffix not calling `basename()` either.
The use would be: `FileUtils::mkpath() << appDirPath << 
(FileUtils::stripExecutableSuffix(FileUtils::basename(launcherPath)) + 
_T(".cfg"));`

-

PR: https://git.openjdk.java.net/jdk/pull/3288

RFR: 8264514: HexFormat implementation tweaks

[Raffaello Giulietti]

Please review these small tweaks.

For background information see 
[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)

Greetings
Raffaello

-

Commit messages:
 - 8264514: HexFormat implementation tweaks

Changes: https://git.openjdk.java.net/jdk/pull/3295/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3295=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264514
  Stats: 67 lines in 1 file changed: 10 ins; 26 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3295/head:pull/3295

PR: https://git.openjdk.java.net/jdk/pull/3295

RFR: 8169629: Annotations with lambda expressions cause AnnotationFormatErrorr

[Joe Darcy]

The stricter checks added by
8035781: Improve equality for annotations
in creating the proxy objects used to implement annotations has an unintended 
by-catch of rejecting annotation's whose type has, say, a field initialized 
with a lambda expression. While uncommon, it is legal code to have a field in 
an annotation type.

The updated checks skip over the sort of synthetic method used for the 
initialization.

Some different compilation tactics were used before and after nest mates, so 
the test includes compilation and testing under both situations.

-

Commit messages:
 - 8169629: Annotations with lambda expressions cause AnnotationFormatErro

Changes: https://git.openjdk.java.net/jdk/pull/3294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3294=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8169629
  Stats: 29 lines in 2 files changed: 25 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3294/head:pull/3294

PR: https://git.openjdk.java.net/jdk/pull/3294

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Maurizio Cimadamore]

On 31/03/2021 21:43, Raffaello Giulietti wrote:

Ciao Maurizio,

admittedly, yours is a fairly convincing argument to wait for the 
completion of Valhalla, or at least JEP 401.


Personally, I wouldn't mind having to denote the primitive class as 
Decimal128.val in some future (2022? 2023? who knows?) if I could use 
Decimal128 tomorrow, but I understand your concerns in defending the 
interests of the community at large (which includes myself).


Well, I think the problem with a lot of these things is consistency. 
Decimal128.val is not horrible, although it is the wrong default (think 
of Decimal128[] which you would probably want flattened?).


The worse aspect is if _some_ of these types are added before, and some 
after, so you have to remember to use Decimal128.val, but HalfFloat is 
ok (as it has been added after Valhalla).


Considering that these things can happen, I'd be reluctant to go ahead 
and add these types now.


What I'd be curious though, is if the @ValueBased annotation could be 
enhanced to say _which_ primitive class default you want (and then javac 
could enforce extra checks if you pick the "val" default). If something 
like this was feasible (cc'ing Dan), maybe some of the friction here 
could be removed?


Maurizio




Greetings
Raffaello



On 31/03/2021 15:23, Douglas Surber wrote:
Rather than waiting on Valhala I would prefer that this project be 
fast tracked and added to OpenJDK ASAP.


There is a catch here.

While in principle, we can add these as value-based classes, and 
migrate to Valhalla later, there is a biggie difference between doing 
it before/after.


When it comes to "migrated" primitive classes, there is a choice in 
how to interpret the "old" utterances of the class name. Let's say 
that class Foo is migrated to be a primitive class; does that mean 
that all uses of Foo in existing program will automatically get 
flattening? Or will references to Foo be interpreted in a 
conservative fashion, so  as to allow the same operations as before? 
One important difference in semantics is assignment to `null` which 
is prohibited under flattened semantics, but allowed under "indirect" 
(or by reference, if you will) semantics.


In other words, under the current plan, if Decimal128 is added now 
and migrated later, utterances of Decimal128 will behave like they 
used to pre-Valhalla, and, to take advantage of flattening you would 
need to opt-in with some keyword (e.g. Decimal128.val).


To me this is kind of a strong argument against going with these 
classes now (as much as I understand how useful they'd be even w/o 
Valhalla) - and preserving the "good" name (Decimal128) for the 
flattened case seems worth, IMHO, waiting few more cycles.


Maurizio

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

[Douglas Surber]

My understanding is that IEEE decimal floating point is intended for currency. 
A large fraction of numeric values stored in databases are currency. It's not 
obvious to me why an e-commerce web site would not want to use Decimal128 to 
represent prices, extensions, taxes, discounts, totals, etc.

> On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti 
>  wrote:
> 
> Hi Douglas,
> 
> yes, different vendors have different limits on the precision, the most 
> extreme probably being PostgreSQL.
> 
> But apart from that, the arithmetic is different.
> 
> A better option is to implement some optimized fixed precision classes like 
> SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. 
> But, as I mentioned, this is something different than Decimal.
> 
> 
> Greetings
> Raffaello
> 
> 
> 
> On 2021-03-31 22:53, Douglas Surber wrote:
>> Understood. The problem is that right now the only appropriate type for 
>> non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of 
>> users avoid it.
>> Decimal128 supports 34 significant digits. The max precision of SQL numeric 
>> types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 
>> 65. So there are a huge range of values representable in SQL that are not 
>> representable in Decimal128. BUT, for the vast majority of applications that 
>> might be tempted to use Decimal128, those non-representable numbers don't 
>> occur. Currency amounts exceeding 34 decimal digits of precision are an 
>> almost non-existent minority.
>> Very few apps will pay the price of using BigDecimal even though it would 
>> support huge numbers exactly. Instead they find workarounds that are more 
>> efficient. Decimal128 would be a substantial improvement for those apps.
>> Douglas
>>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I think there's a misunderstanding about the nature of IEEE 754 Decimal 
>>> (e.g., Decimal64), the subject of this thread, and the nature of SQL 
>>> DECIMAL(p, s).
>>> 
>>> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall 
>>> maximum precision p and a scale s, the number of digits to the right of the 
>>> decimal point (both parameters can be selected freely inside some ranges). 
>>> For example, DECIMAL(2, 1) can represent only the values
>>>-9.9, -9.8, ..., 9.8, 9.9
>>> and that's it.
>>> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
>>> 
>>> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal 
>>> of precision 2 can represent values of the form c*10^q, where integer c 
>>> meets |c| < 100 (that is, max two digits) and integer q is limited in some 
>>> range. It covers the values above and much more, for example, 0.012 
>>> (=12*10^(-3)) and -3.4E2 (=-34*10^1).
>>> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is 
>>> rounded to the closest number of precision 2 (assuming 
>>> RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 
>>> 12, which is 11.6 rounded to 2 digits.
>>> But really, the position of the decimal point is floating.
>>> 
>>> IEEE decimals and SQL decimals are fundamentally different and ave 
>>> different arithmetic, so I wouldn't recommend using the proposed classes 
>>> for JDBC.
>>> 
>>> On the positive side, SQL decimals, are easier to implement if the maximum 
>>> allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
>>> 
>>> 
>>> Greetings
>>> Raffaello

Re: Proposed: StringUTF16 bug fix with optimization - Part 1 of 2, StringUTF16 Patch

[Naoto Sato]

Hi Chris,

Thank you for your contribution. I believe this can be divided into two 
parts, one is the bug in the current implementation, and the other is 
the enhancement to refactor the whole implementation for performance. I 
have created two JIRA issues for each:


https://bugs.openjdk.java.net/browse/JDK-8264544
https://bugs.openjdk.java.net/browse/JDK-8264545

The former one is really an embarassing one that I would want to fix 
right away. I think the latter one need more eyes. Comments from others 
are welcome.


Naoto

On 3/30/21 4:44 PM, Chris Johnson wrote:

Historically, the methods currently known as "compareToCI" and
"regionMatchesCI", and located in "java.lang.StringUTF16", have lacked
support for Supplementary Multilingual Plane code-points. (I've seen no
associated bug.)

On July 23, 2020 the first fix for the bug was committed. However, it
includes two simple bugs of its own. They're not much more than typos,
but they break some things nonetheless, as demonstrated by the unit
tests comprising part 2 of this contribution.

(Those two bugs: In "StringUTF16.compareToCIImpl", change statements
"cp1 -= cp1;" and "cp2 -= cp2;" to, respectively, "cp1 = -cp1;" and
"cp2 = -cp2;", and those bugs are history.)

The fixed "compareToCI" and "regionMatchesCI" methods in this patch are
different, however.[1] Notably:

   1. Case-insensitive UTF-16 string comparison and equality-testing is
  2.2 to 2.9 times faster than the current methods, depending on data
  set composition. (So, meaningfully faster, but the degree varies
  with the strings compared.)

   2. 100% TestNG unit test coverage.

   3. A utility method, "compareCodePointsIgnoringCase", created for these
  methods increased their performance by 24%, and could, in the future,
  be applied easily to "StringLatin1" methods "compareToCI*", and
  "regionMatchesCI*". (My guess is the performance gain there will be
  smaller, but still useful.)

This patch to "StringUTF16" may appear quite large. For better or worse
(your call, gentle reader), the vast majority of it is comments. The code
itself is minimal by comparison.

Thanks in advance for your consideration,

Chris

Chris W. Johnson
chriswjohnson@gmail.com
http://www.panojohnson.com/


Footnote:

1. Work on this code began around 4 years ago, when I failed to find a
bug report link on the OpenJDK page, and supposed the message to devs
might be something like "contribute or go away". Since then, life,
death, work, learning to build & test OpenJDK, registering as a
contributor, social anxiety, unit test development, benchmarking,
experimentation, and being unable to look at my own code without
seeing *something* to improve (especially considering it might end-up
in the JDK), are among the reasons for the long delay in attempting
this contribution.






Index: src/java.base/share/classes/java/lang/StringUTF16.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>US-ASCII
===
diff --git a/src/java.base/share/classes/java/lang/StringUTF16.java
b/src/java.base/share/classes/java/lang/StringUTF16.java
--- a/src/java.base/share/classes/java/lang/StringUTF16.java(revision
60819:ee1d592a9f5389725a0338a4b5dfcf4fc3fcf20c)
+++ b/src/java.base/share/classes/java/lang/StringUTF16.java(revision
60819+:ee1d592a9f53+)
@@ -41,7 +41,32 @@
  import static java.lang.String.LATIN1;

  final class StringUTF16 {
-
+
+/**
+ * Number of low-order bits storing the payload of Unicode surrogate
code-units.
+ * (The number of surrogate header bits is {@link Character#SIZE}
minus this value.)
+ */
+private static final intSURROGATE_PAYLOAD_BIT_COUNT = 10;
+
+/**
+ * The high six bits common to all high-surrogate code-units (bits
15-10) right-shifted into bits
+ * 5-0 of an "{@code int}" primitive. ({@code 0b1101_10**__

10 == 0b11_0110 == 0x36})

+ */
+private static final intSURROGATE_HI_HEADER_RIGHT_SHIFTED_10 =
Character.MIN_HIGH_SURROGATE >>> SURROGATE_PAYLOAD_BIT_COUNT;  // == 0x36
+
+/**
+ * Produces a Supplementary Multilingual Plane code-point when added
to a valid surrogate-pair
+ * combined as follows: {@code (highSurrogate <<
SURROGATE_PAYLOAD_BIT_COUNT) + lowSurrogate}.
+ * The result is undefined if either would-be surrogate is invalid
(not a surrogate code-unit,
+ * or the wrong surrogate type [low instead of high, or vice versa]).
+ *
+ * @see Character#toCodePoint(char, char)
+ */
+private static final intSURROGATE_COMBO_TO_CODE_POINT_DELTA =
  Character.MIN_SUPPLEMENTARY_CODE_POINT
+-
(Character.MIN_HIGH_SURROGATE << SURROGATE_PAYLOAD_BIT_COUNT)
+-
  Character.MIN_LOW_SURROGATE;  // -56_613_888
+
+
  

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

Hi Douglas,

yes, different vendors have different limits on the precision, the most 
extreme probably being PostgreSQL.


But apart from that, the arithmetic is different.

A better option is to implement some optimized fixed precision classes 
like SQLDecimal38 and SQLDecimal65 + a more general variable precision 
SQLDecimal. But, as I mentioned, this is something different than 
Decimal.



Greetings
Raffaello



On 2021-03-31 22:53, Douglas Surber wrote:

Understood. The problem is that right now the only appropriate type for 
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of 
users avoid it.

Decimal128 supports 34 significant digits. The max precision of SQL numeric 
types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. 
So there are a huge range of values representable in SQL that are not 
representable in Decimal128. BUT, for the vast majority of applications that 
might be tempted to use Decimal128, those non-representable numbers don't 
occur. Currency amounts exceeding 34 decimal digits of precision are an almost 
non-existent minority.

Very few apps will pay the price of using BigDecimal even though it would 
support huge numbers exactly. Instead they find workarounds that are more 
efficient. Decimal128 would be a substantial improvement for those apps.

Douglas


On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti 
 wrote:

Hi,

I think there's a misunderstanding about the nature of IEEE 754 Decimal 
(e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).

SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall 
maximum precision p and a scale s, the number of digits to the right of the 
decimal point (both parameters can be selected freely inside some ranges). For 
example, DECIMAL(2, 1) can represent only the values
-9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.

IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of 
precision 2 can represent values of the form c*10^q, where integer c meets |c| 
< 100 (that is, max two digits) and integer q is limited in some range. It 
covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 
(=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded 
to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the 
same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
But really, the position of the decimal point is floating.

IEEE decimals and SQL decimals are fundamentally different and ave different 
arithmetic, so I wouldn't recommend using the proposed classes for JDBC.

On the positive side, SQL decimals, are easier to implement if the maximum 
allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.


Greetings
Raffaello

Re: [External] : Re: Proposal for Decimal64 and Decimal128 value-based classes

[Douglas Surber]

Understood. The problem is that right now the only appropriate type for 
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of 
users avoid it. 

Decimal128 supports 34 significant digits. The max precision of SQL numeric 
types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. 
So there are a huge range of values representable in SQL that are not 
representable in Decimal128. BUT, for the vast majority of applications that 
might be tempted to use Decimal128, those non-representable numbers don't 
occur. Currency amounts exceeding 34 decimal digits of precision are an almost 
non-existent minority.

Very few apps will pay the price of using BigDecimal even though it would 
support huge numbers exactly. Instead they find workarounds that are more 
efficient. Decimal128 would be a substantial improvement for those apps.

Douglas

> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti 
>  wrote:
> 
> Hi,
> 
> I think there's a misunderstanding about the nature of IEEE 754 Decimal 
> (e.g., Decimal64), the subject of this thread, and the nature of SQL 
> DECIMAL(p, s).
> 
> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall 
> maximum precision p and a scale s, the number of digits to the right of the 
> decimal point (both parameters can be selected freely inside some ranges). 
> For example, DECIMAL(2, 1) can represent only the values
>-9.9, -9.8, ..., 9.8, 9.9
> and that's it.
> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
> 
> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of 
> precision 2 can represent values of the form c*10^q, where integer c meets 
> |c| < 100 (that is, max two digits) and integer q is limited in some range. 
> It covers the values above and much more, for example, 0.012 (=12*10^(-3)) 
> and -3.4E2 (=-34*10^1).
> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded 
> to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By 
> the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 
> digits.
> But really, the position of the decimal point is floating.
> 
> IEEE decimals and SQL decimals are fundamentally different and ave different 
> arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
> 
> On the positive side, SQL decimals, are easier to implement if the maximum 
> allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
> 
> 
> Greetings
> Raffaello

RFR: 8037397: Lost nested character class after intersection &

[Ian Graves]

Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, 
some character classes on the right hand side of the operator are dropped in 
cases where nested `[..]` classes are used with non "nested" ones.

-

Commit messages:
 - Fixing a regex intersection bug that drops expressions on the right hand side

Changes: https://git.openjdk.java.net/jdk/pull/3291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3291=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8037397
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3291/head:pull/3291

PR: https://git.openjdk.java.net/jdk/pull/3291

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

Ciao Maurizio,

admittedly, yours is a fairly convincing argument to wait for the 
completion of Valhalla, or at least JEP 401.


Personally, I wouldn't mind having to denote the primitive class as 
Decimal128.val in some future (2022? 2023? who knows?) if I could use 
Decimal128 tomorrow, but I understand your concerns in defending the 
interests of the community at large (which includes myself).



Greetings
Raffaello



On 31/03/2021 15:23, Douglas Surber wrote:

Rather than waiting on Valhala I would prefer that this project be fast tracked 
and added to OpenJDK ASAP.


There is a catch here.

While in principle, we can add these as value-based classes, and migrate 
to Valhalla later, there is a biggie difference between doing it 
before/after.


When it comes to "migrated" primitive classes, there is a choice in how 
to interpret the "old" utterances of the class name. Let's say that 
class Foo is migrated to be a primitive class; does that mean that all 
uses of Foo in existing program will automatically get flattening? Or 
will references to Foo be interpreted in a conservative fashion, so  as 
to allow the same operations as before? One important difference in 
semantics is assignment to `null` which is prohibited under flattened 
semantics, but allowed under "indirect" (or by reference, if you will) 
semantics.


In other words, under the current plan, if Decimal128 is added now and 
migrated later, utterances of Decimal128 will behave like they used to 
pre-Valhalla, and, to take advantage of flattening you would need to 
opt-in with some keyword (e.g. Decimal128.val).


To me this is kind of a strong argument against going with these classes 
now (as much as I understand how useful they'd be even w/o Valhalla) - 
and preserving the "good" name (Decimal128) for the flattened case seems 
worth, IMHO, waiting few more cycles.


Maurizio

RFR: JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching

[Andy Herrick]

Deriving the cfg file name is broken on mac and linux when the application name 
has a "." in it.

-

Commit messages:
 - Merge branch 'master' into JDK-8264403
 - JDK-8264403: [macos]: App names containing '.' characters results in an 
error message when launching
 - 8264466: Cut-paste error in InterfaceCalls JMH
 - 8264149: BreakpointInfo::set allocates metaspace object in VM thread
 - 8264417: ParallelCompactData::region_offset should not accept pointers 
outside the current region
 - 8264112: (fs) Reorder methods/constructor/fields in 
UnixUserDefinedFileAttributeView.java
 - 8261957: [PPC64] Support for Concurrent Thread-Stack Processing
 - 8262894: [macos_aarch64] SIGBUS in Assembler::ld_st2
 - 8263582: WB_IsMethodCompilable ignores compiler directives
 - 8244540: Print more information with -XX:+PrintSharedArchiveAndExit
 - ... and 65 more: https://git.openjdk.java.net/jdk/compare/6225ae63...1fe2699e

Changes: https://git.openjdk.java.net/jdk/pull/3288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3288=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264403
  Stats: 82 lines in 5 files changed: 80 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3288.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3288/head:pull/3288

PR: https://git.openjdk.java.net/jdk/pull/3288

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

Hi,

I think there's a misunderstanding about the nature of IEEE 754 
Decimal (e.g., Decimal64), the subject of this thread, and the nature 
of SQL DECIMAL(p, s).


SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an 
overall maximum precision p and a scale s, the number of digits to the 
right of the decimal point (both parameters can be selected freely 
inside some ranges). For example, DECIMAL(2, 1) can represent only the 
values

-9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.

IEEE decimals are *floating* point decimal numbers. A hypothetical 
decimal of precision 2 can represent values of the form c*10^q, where 
integer c meets |c| < 100 (that is, max two digits) and integer q is 
limited in some range. It covers the values above and much more, for 
example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is 
rounded to the closest number of precision 2 (assuming 
RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 
12, which is 11.6 rounded to 2 digits.

But really, the position of the decimal point is floating.

IEEE decimals and SQL decimals are fundamentally different and ave 
different arithmetic, so I wouldn't recommend using the proposed classes 
for JDBC.


On the positive side, SQL decimals, are easier to implement if the 
maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's 
another topic.



Greetings
Raffaello

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing [v2]

[Brent Christian]

On Wed, 31 Mar 2021 12:47:50 GMT, Aleksei Efimov  wrote:

>> Current fix tries to tackle an issue with URL connection referencing 
>> non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the 
>> underlying Jar file is still cached even if an exception is thrown after 
>> that. Such behavior prevents the caller, for instance, a `URLClassLoader`, 
>> from closing a Jar file.
>> 
>> The proposed fix checks if entry exists before caching a Jar file (only for 
>> cases with enabled caching):
>> - If entry exists - jar file is cached if it wasn't cached before
>> - If entry doesn't exist and jar file wasn't cached before - jar file is 
>> closed and exception is thrown
>> - If entry doesn't exist and jar file was cached before - jar file is kept 
>> cached and exception is thrown
>> 
>> 
>> The following tests have been used to verify the fix:
>> - New regression tests
>> - ``:jdk_core:`` tests
>> - `api/java_util`,`api/java_net` JCK tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8264048: Remove old version of RemoveJar test

Hi, Aleksei.  The change looks good.

-

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3263

Re: RFR: 8173970: jar tool should have a way to extract to a directory [v3]

[Lance Andersen]

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this patch which proposes to implement the 
>> enhancement request noted in 
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the 
>> `jar` command. The option takes a path to a destination directory as a value 
>> and extracts the contents of the jar into that directory. This is an 
>> optional option and the changes in the commit continue to maintain backward 
>> compatibility where the jar is extracted into current directory, if no `-o` 
>> or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this 
>> new option should be. I was initially thinking of using `-d` but that is 
>> currently used by the `jar` command for a different purpose. So I decided to 
>> use `-o` and `--output-dir`. This is of course open for change depending on 
>> any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains 
>> the English version of the jar command's `--help` output. However, no 
>> changes have been done to the internationalization files corresponding to 
>> this one (for example: `jar_de.properties`), because I don't know what 
>> process needs to be followed to have those files updated (if at all they 
>> need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this 
>> new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Alan's review feedback for -C help text
>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP

Some additional comments basically suggesting that we test --extract in 
addition to -x

test/jdk/tools/jar/JarExtractTest.java line 175:

> 173: final String dest = "foo-bar";
> 174: System.out.println("Extracting " + testJarPath + " to " + dest);
> 175: final int exitCode = JAR_TOOL.run(System.out, System.err, "-x", 
> "-f", testJarPath.toString(),

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 216:

> 214: final Path jarPath = createJarWithPFlagSemantics();
> 215: // extract with -P flag without any explicit destination 
> directory (expect the extraction to work fine)
> 216: final String[] args = new String[]{"-xvfP", jarPath.toString()};

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 239:

> 237:  */
> 238: @Test
> 239: public void testExtractWithDirPFlagNotAllowed() throws Exception {

I would include --extract in your testing options

test/jdk/tools/jar/JarExtractTest.java line 240:

> 238: @Test
> 239: public void testExtractWithDirPFlagNotAllowed() throws Exception {
> 240: final String expectedErrMsg = "-P option cannot be used when 
> extracting a jar to a specific location";

Probably need to add a comment that this must match the entry in jar.properties

test/jdk/tools/jar/JarExtractTest.java line 247:

> 245: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), 
> "-P", "-C", "."});
> 246: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), 
> "-P", "--dir", "."});
> 247: cmdArgs.add(new String[]{"-xvfP", testJarPath.toString(), "-C", 
> tmpDir});

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 262:

> 260:  */
> 261: @Test
> 262: public void testLegacyCompatibilityMode() throws Exception {

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 282:

> 280: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), 
> "-C", tmpDir, "-C", tmpDir});
> 281: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), 
> "--dir", tmpDir, "--dir", tmpDir});
> 282: cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), 
> "--dir", tmpDir, "-C", tmpDir});

Perhaps use a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 300:

> 298: public void testExtractPartialContent() throws Exception {
> 299: final String tmpDir = Files.createTempDirectory(Path.of("."), 
> "8173970-").toString();
> 300: final String[] cmdArgs = new String[]{"-x", "-f", 
> testJarPath.toString(), "--dir", tmpDir,

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 332:

> 330:  */
> 331: private void testExtract(final String dest) throws Exception {
> 332: final String[] args = new String[]{"-x", "-f", 
> testJarPath.toString(), "-C", dest};

Perhaps add a DataProvider so you can test --extract as well?

-

PR: https://git.openjdk.java.net/jdk/pull/2752

Re: Insufficiencies in JEP: 400: UTF-8 by Default

[Roger Riggs]

Hi Anthony,

A draft of updates to the Process API is in the works and covers improving
the ease of use and providing Readers and Writers.  Note that if process 
output
is redirected to a file, it does not interpose on the byte streams and 
is not in

a position to affect the character set used by the child process.

Regards, Roger


On 3/30/21 1:03 PM, Anthony Vanelverdinghe wrote:

Hi Alan

As Marco mentioned, another use case is sub-process stdin/stdout/stderr. In my 
particular instance, I'm starting a Process which has its output redirected to 
a file. It uses the platform's default encoding for writing to stdout. So when 
I want to read its output from the file at some later point, I need to supply 
that encoding to the Files API.
One way to accommodate this use case, is a method which allows to retrieve the 
platform's default encoding, for example a method `platformEncoding` in Charset or 
Process, or the `Console::charset` method you mentioned. Another option would be to 
enhance the Process API, by adding methods to Process which return appropriate 
Readers/Writers & adding methods of the form `redirectX(File file, Charset 
encoding)` to ProcessBuilder. But this seems like a lot of additional API surface, 
just to avoid surfacing the platform's default encoding itself.
So I think the JEP should specify how it'll address use cases w.r.t. the 
Process API, shouldn't it?

Kind regards,
Anthony
  
On Sunday, March 14, 2021 13:01 CET, Alan Bateman  wrote:
  

On 14/03/2021 11:00, Marco wrote:

:

IMO Charset should provide standardized getters for the OS charset and the
console charset. The latter being different has been a long standing issue on
Windows where the codepage differs between its CLI and regular environments.
OpenJDK has the necessary data already available in its custom system
properties.

The console charset is currently hidden behind PrintStream not exposing the
underlying OSWriter and not offering getEncoding() itself. The OS charset
would be hidden in the future by Charset.getDefaultCharset()'s specification
change in JEP 400.

The intention that there will be little or no impact to the console
streams. This means that java.io.Console reader/writer methods should
continue to return a Reader/PrintWriter that uses the platform encoding
(or code page is on Windows). Same thing for the System.out/System.err
print streams. We need to make this clearer in the JEP.

There has been discussion on this mailing list about adding a
Console::charset method but it didn't come to a consensus. Naoto Sato
and I have been chatting about it again recently as there may be a need
to add an API in advance of proposing to target the JEP.

One case that we are still mulling over is code that creates an
InputStreamReader on System.in without specifying the charset. This
might be older code that pre-dates java.io.Console or maybe code that
wasn't tested on a wide range or platforms. Options range from a spec
change to doing nothing (the latter meaning running with "COMPACT" or
migrating the code to use the 2-arg constructor as the default charset
is not the right choice).

-Alan

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

[Stefan Karlsson]

On Wed, 31 Mar 2021 15:42:14 GMT, Brian Burkhalter  wrote:

>> Stefan Karlsson has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Review Alan
>
> Marked as reviewed by bpb (Reviewer).

Thanks for reviewing!

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Integrated: 8264489: Add more logging to LargeCopyWithMark.java

[Stefan Karlsson]

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson  wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more 
> information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one 
> Review.

This pull request has now been integrated.

Changeset: 0fa35728
Author:Stefan Karlsson 
URL:   https://git.openjdk.java.net/jdk/commit/0fa35728
Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8264489: Add more logging to LargeCopyWithMark.java

Reviewed-by: kbarrett, alanb, bpb

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Douglas Surber]

I'm sure this would be a huge disruption, but I'll throw it out anyway. I'd be 
perfectly happy if assigning null to a Decimal64/128 container was not allowed, 
whether it is a reference or a value.

I haven't followed the progress of Valhalla closely. It would be reasonable to 
delay Decimal64/128 until Valhalla so long as that isn't more than a very few 
cycles. My concern is that Valhalla is a challenging project. I would not want 
Decimal64/128 to get hung up because Valhalla is delayed or even worse canceled.

Douglas

> On Mar 31, 2021, at 8:01 AM, Maurizio Cimadamore 
>  wrote:
> 
> 
> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast 
>> tracked and added to OpenJDK ASAP.
> 
> There is a catch here.
> 
> While in principle, we can add these as value-based classes, and migrate to 
> Valhalla later, there is a biggie difference between doing it before/after.
> 
> When it comes to "migrated" primitive classes, there is a choice in how to 
> interpret the "old" utterances of the class name. Let's say that class Foo is 
> migrated to be a primitive class; does that mean that all uses of Foo in 
> existing program will automatically get flattening? Or will references to Foo 
> be interpreted in a conservative fashion, so  as to allow the same operations 
> as before? One important difference in semantics is assignment to `null` 
> which is prohibited under flattened semantics, but allowed under "indirect" 
> (or by reference, if you will) semantics.
> 
> In other words, under the current plan, if Decimal128 is added now and 
> migrated later, utterances of Decimal128 will behave like they used to 
> pre-Valhalla, and, to take advantage of flattening you would need to opt-in 
> with some keyword (e.g. Decimal128.val).
> 
> To me this is kind of a strong argument against going with these classes now 
> (as much as I understand how useful they'd be even w/o Valhalla) - and 
> preserving the "good" name (Decimal128) for the flattened case seems worth, 
> IMHO, waiting few more cycles.
> 
> Maurizio
> 

Re: RFR: 8264109: Add vectorized implementation for VectorMask.andNot()

[Paul Sandoz]

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong  wrote:

> Currently "VectorMask.andNot()" is not vectorized:
> public VectorMask andNot(VectorMask m) {
> // FIXME: Generate good code here.
> return bOp(m, (i, a, b) -> a && !b);
> }
> This can be implemented with` "and(m.not())" `directly. Since 
> `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
> boolean[] mask = fm.apply(SPECIES.length());
> boolean[] r = fmt.apply(SPECIES.length());
> VectorMask rm = VectorMask.fromArray(SPECIES, r, 0);
> 
> for (int ic = 0; ic < INVOC_COUNT; ic++) {
>   for (int i = 0; i < mask.length; i += SPECIES.length()) {
> VectorMask vmask = VectorMask.fromArray(SPECIES, mask, i);
>   rm = rm.andNot(vmask);
> }
> }
> return rm;
>   }

Would you mind updating the existing `AbstractMask.andNot` implementation? 
rather than changing `VectorMask.andNot`. That fits in with the current 
implementation pattern.

-

PR: https://git.openjdk.java.net/jdk/pull/3211

Re: RFR: 8173970: jar tool should have a way to extract to a directory [v3]

[Lance Andersen]

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this patch which proposes to implement the 
>> enhancement request noted in 
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the 
>> `jar` command. The option takes a path to a destination directory as a value 
>> and extracts the contents of the jar into that directory. This is an 
>> optional option and the changes in the commit continue to maintain backward 
>> compatibility where the jar is extracted into current directory, if no `-o` 
>> or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this 
>> new option should be. I was initially thinking of using `-d` but that is 
>> currently used by the `jar` command for a different purpose. So I decided to 
>> use `-o` and `--output-dir`. This is of course open for change depending on 
>> any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains 
>> the English version of the jar command's `--help` output. However, no 
>> changes have been done to the internationalization files corresponding to 
>> this one (for example: `jar_de.properties`), because I don't know what 
>> process needs to be followed to have those files updated (if at all they 
>> need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this 
>> new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Alan's review feedback for -C help text
>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP

Hi Jaikiran

Overall this looks good.  I have a few comments below and will look at the CSR 
shortly.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1427:

> 1425: return rc;// leading '/' or 'dot-dot' only path
> 1426: }
> 1427: File f = new File(xdestDir, name.replace('/', 
> File.separatorChar));

Could you please add a comment regarding xdestDir and also correct the typo on 
line 1418 'requres' -> 'requires'

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 62:

> 60: Could not create a temporary file
> 61: error.extract.multiple.dest.dir=\
> 62: You may not specify more than one directory for extracting the jar

Perhaps something similar to:

You may not specify  the  '-C' or '--dir' option more than once with the '-x' 
option

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 64:

> 62: You may not specify more than one directory for extracting the jar
> 63: error.extract.pflag.not.allowed=\
> 64: -P option cannot be used when extracting a jar to a specific 
> location

Perhaps something similar to

You may not specify '-Px'  with the '-C' or '--dir' options

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 167:

> 165: (in = {0}) (out= {1})
> 166: out.extract.dir=\
> 167: extracting to {0}

Perhaps 'Extracting to directory: {0}'

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 249:

> 247: \  -C DIR Change to the specified directory and 
> include the\n\
> 248: \ following file. When used in extract mode, 
> extracts\n\
> 249: \ the jar to the specified directory

Should this be updated on line 187 as well in the compatibility mode section?

test/jdk/tools/jar/JarExtractTest.java line 152:

> 150: return abs;
> 151: }
> 152: 

Please add a comment to each test giving a high level overview of what it does 
as it will help future maintainers

test/jdk/tools/jar/JarExtractTest.java line 307:

> 305: // make sure only the specific files were extracted
> 306: final Stream paths = Files.walk(Path.of(tmpDir));
> 307: Assert.assertEquals(paths.count(), 6, "Unexpected number of 
> files/dirs in " + tmpDir);

Should '6' be in a local variable to make it clearer or at a minimum a comment

test/jdk/tools/jar/JarExtractTest.java line 367:

> 365: }
> 366: 
> 367: private static Path createJarWithPFlagSemantics() throws IOException 
> {

Perhaps add a comment as to what the method does

-

PR: https://git.openjdk.java.net/jdk/pull/2752

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

[Brian Burkhalter]

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson  wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more 
>> information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one 
>> Review.
>
> Stefan Karlsson has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Review Alan

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Maurizio Cimadamore]

On 31/03/2021 15:23, Douglas Surber wrote:

Rather than waiting on Valhala I would prefer that this project be fast tracked 
and added to OpenJDK ASAP.


There is a catch here.

While in principle, we can add these as value-based classes, and migrate 
to Valhalla later, there is a biggie difference between doing it 
before/after.


When it comes to "migrated" primitive classes, there is a choice in how 
to interpret the "old" utterances of the class name. Let's say that 
class Foo is migrated to be a primitive class; does that mean that all 
uses of Foo in existing program will automatically get flattening? Or 
will references to Foo be interpreted in a conservative fashion, so  as 
to allow the same operations as before? One important difference in 
semantics is assignment to `null` which is prohibited under flattened 
semantics, but allowed under "indirect" (or by reference, if you will) 
semantics.


In other words, under the current plan, if Decimal128 is added now and 
migrated later, utterances of Decimal128 will behave like they used to 
pre-Valhalla, and, to take advantage of flattening you would need to 
opt-in with some keyword (e.g. Decimal128.val).


To me this is kind of a strong argument against going with these classes 
now (as much as I understand how useful they'd be even w/o Valhalla) - 
and preserving the "good" name (Decimal128) for the flattened case seems 
worth, IMHO, waiting few more cycles.


Maurizio

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Lance Andersen]

Agree this could be beneficial to JDBC users.  To officially support this in 
JDBC would require an MR but as Douglas indicates  the work required to the 
JDBC spec would be minimal

Best
Lance

On Mar 31, 2021, at 10:23 AM, Douglas Surber 
mailto:douglas.sur...@oracle.com>> wrote:

+1

JDBC would support this immediately. All it would take is the addition of a 
couple of lines in some appendices to require that conforming implementations 
of getObject(int, Class), setObject(int, Object, SQLType), etc support 
Decimal64 and Decimal128. No change to the API required. Driver vendors could 
add this support the instant the types are available, no need to wait for a 
change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal 
with money in some form. Binary floats are inappropriate for money and 
BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked 
and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, 
core-libs-dev-requ...@openjdk.java.net
 wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz 
mailto:brian.go...@oracle.com>>
To: Raffaello Giulietti 
mailto:raffaello.giulie...@gmail.com>>,
 Paul Sandoz
mailto:paul.san...@oracle.com>>
Cc: core-libs-dev 
mailto:core-libs-dev@openjdk.java.net>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: 
<64334a24-0e4c-57b8-b666-447ca3508...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Douglas Surber]

+1

JDBC would support this immediately. All it would take is the addition of a 
couple of lines in some appendices to require that conforming implementations 
of getObject(int, Class), setObject(int, Object, SQLType), etc support 
Decimal64 and Decimal128. No change to the API required. Driver vendors could 
add this support the instant the types are available, no need to wait for a 
change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal 
with money in some form. Binary floats are inappropriate for money and 
BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked 
and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, 
core-libs-dev-requ...@openjdk.java.net
 wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz mailto:brian.go...@oracle.com>>
To: Raffaello Giulietti 
mailto:raffaello.giulie...@gmail.com>>, Paul 
Sandoz
mailto:paul.san...@oracle.com>>
Cc: core-libs-dev 
mailto:core-libs-dev@openjdk.java.net>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: 
<64334a24-0e4c-57b8-b666-447ca3508...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.

Re: Further review of java.util.HexFormat

[Roger Riggs]

Hi Raffaello,

None of these are substantive but useful none the less.
I would have rather seen them during the review and not be revisiting them.

Issue created: 8264514 
 HexFormat 
implementation tweaks


On 3/30/21 8:19 PM, Raffaello Giulietti wrote:

Hello Roger,


these are the changes I'm proposing after reviewing the code of 
j.u.HexFormat. The modified code available here
https://urldefense.com/v3/__https://github.com/rgiulietti/jdk/commit/6759a25eb952ab19a045a83349d41b82cc1b07cb__;!!GqivPVa7Brio!JLXpQq2CQ_x4RuLDCYWukMvEBq8yc6hUH8q7U0stTiQjEgvx6yn_h_2gwUMfmMgI$ 

In addition to other smaller, hopefully self-explanatory enhancements, 
here are the rationales for the changes.



Static field DIGITS should preferably be formatted with 16 values/line 
to ease a visual positional crosscheck with published ASCII/IsoLatin1 
tables.
yes, but as is are easier to index using decimal values.  (20 per line 
and more compact).



Field digits is initialized with either UPPERCASE_DIGITS, 
LOWERCASE_DIGITS or digits from another instance, so it always ends up 
being either UPPERCASE_DIGITS or LOWERCASE_DIGITS.

Consequently:
* There's no need for requireNonNull() check in the (sole) private 
constructor.
* It's preferable to move the last comparison in method equals() as 
the first factor in the return statement, so it can return faster in 
case of a lower/upper mismatch. (Arrays.equals() first checks for ==, 
so it always returns fast as used in this class. It could even be 
replaced by a simple == )

Though perhaps less intuitive and not performance sensitive.



Method fromHexDigits(CharSequence, int) either returns a value in the 
range [0x00..0xff] or throws.
Therefore, there's no need for the checks leading to the throwing of 
IllegalArgumentException in methods

* parseHex(CharSequence, int, int)
* parseNoDelimiter(CharSequence)
which can be simplified as a consequence.

The private fromHexDigits method did not originally throw.
An @throws ILE should be added



The test for IllegalArgumentException in method parseHex(CharSequence, 
int, int), namely
string.length() < valueChars || (string.length() - valueChars) % 
stride != 0

can be simplified as
(string.length() - valueChars) % stride != 0

Indeed, at this point in the control flow we have
string.length() > 0  and  stride >= valueChars
Assuming string.length() < valueChars as in the left operand of || we 
then have

-stride <= -valueChars < string.length() - valueChars < 0
so
string.length() - valueChars) % stride != 0
which is the right operand of ||.
In other words, the left operand always implies the right one, adding 
nothing to it.



There's no need to check again for non-nullness in private method 
fromHexDigits(CharSequence, int). It is invoked from two places where 
the check is already performed.

Though the checking seems redundant it documents the requirement.
The hotspot compiler squashes out any redundancy, so there is no 
performance impact.



Both fromHexDigits(CharSequence) and fromHexDigitsToLong(CharSequence) 
can simply invoke their 3 args counterparts.

At a slightly higher overhead to add the offset.



If you prefer, I can prepare a PR once there's an issue in the bug 
system to associate the PR with.




Thanks, Roger



Greetings
Raffaello

Re: RFR: 8173970: jar tool should have a way to extract to a directory

[Jaikiran Pai]

On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman  wrote:

>> Can I please get a review for this patch which proposes to implement the 
>> enhancement request noted in 
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the 
>> `jar` command. The option takes a path to a destination directory as a value 
>> and extracts the contents of the jar into that directory. This is an 
>> optional option and the changes in the commit continue to maintain backward 
>> compatibility where the jar is extracted into current directory, if no `-o` 
>> or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this 
>> new option should be. I was initially thinking of using `-d` but that is 
>> currently used by the `jar` command for a different purpose. So I decided to 
>> use `-o` and `--output-dir`. This is of course open for change depending on 
>> any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains 
>> the English version of the jar command's `--help` output. However, no 
>> changes have been done to the internationalization files corresponding to 
>> this one (for example: `jar_de.properties`), because I don't know what 
>> process needs to be followed to have those files updated (if at all they 
>> need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this 
>> new option.
>
> I think the summary is that we've converged on -C/--dir. We might have to 
> tweak the usage message for -C so that it starts with the existing "Change to 
> the specified directory ..." rather than changing it to start with the 
> extract case.
> Are you, or Lance, going to create the CSR for this?

A CSR for this enhancement has now been created 
https://bugs.openjdk.java.net/browse/JDK-8264510

-

PR: https://git.openjdk.java.net/jdk/pull/2752

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing [v2]

[Aleksei Efimov]

> Current fix tries to tackle an issue with URL connection referencing 
> non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the 
> underlying Jar file is still cached even if an exception is thrown after 
> that. Such behavior prevents the caller, for instance, a `URLClassLoader`, 
> from closing a Jar file.
> 
> The proposed fix checks if entry exists before caching a Jar file (only for 
> cases with enabled caching):
> - If entry exists - jar file is cached if it wasn't cached before
> - If entry doesn't exist and jar file wasn't cached before - jar file is 
> closed and exception is thrown
> - If entry doesn't exist and jar file was cached before - jar file is kept 
> cached and exception is thrown
> 
> 
> The following tests have been used to verify the fix:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests

Aleksei Efimov has updated the pull request incrementally with one additional 
commit since the last revision:

  JDK-8264048: Remove old version of RemoveJar test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3263/files
  - new: https://git.openjdk.java.net/jdk/pull/3263/files/6aeb..2f0fa527

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3263=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3263=00-01

  Stats: 179 lines in 1 file changed: 0 ins; 179 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3263/head:pull/3263

PR: https://git.openjdk.java.net/jdk/pull/3263

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing

[Aleksei Efimov]

On Wed, 31 Mar 2021 11:24:02 GMT, Daniel Fuchs  wrote:

>> Current fix tries to tackle an issue with URL connection referencing 
>> non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the 
>> underlying Jar file is still cached even if an exception is thrown after 
>> that. Such behavior prevents the caller, for instance, a `URLClassLoader`, 
>> from closing a Jar file.
>> 
>> The proposed fix checks if entry exists before caching a Jar file (only for 
>> cases with enabled caching):
>> - If entry exists - jar file is cached if it wasn't cached before
>> - If entry doesn't exist and jar file wasn't cached before - jar file is 
>> closed and exception is thrown
>> - If entry doesn't exist and jar file was cached before - jar file is kept 
>> cached and exception is thrown
>> 
>> 
>> The following tests have been used to verify the fix:
>> - New regression tests
>> - ``:jdk_core:`` tests
>> - `api/java_util`,`api/java_net` JCK tests
>
> Hi Aleksei, thanks for putting this together.
> 
> `test/jdk/sun/misc/URLClassPath/RemoveJar.java` seems to be an older version 
> of `test/jdk/java/net/URLClassLoader/RemoveJar.java`. The two tests are 
> almost identical - so `test/jdk/sun/misc/URLClassPath/RemoveJar.java` can 
> probably be removed from the PR.
> 
> Otherwise the proposed changes look good to me.

Thanks for the review, Daniel. It is correct that 
`test/jdk/sun/misc/URLClassPath/RemoveJar.java` is an old version. It is 
removed now.

-

PR: https://git.openjdk.java.net/jdk/pull/3263

Re: RFR: 8264048: Fix caching in Jar URL connections when an entry is missing

[Daniel Fuchs]

On Tue, 30 Mar 2021 11:30:48 GMT, Aleksei Efimov  wrote:

> Current fix tries to tackle an issue with URL connection referencing 
> non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the 
> underlying Jar file is still cached even if an exception is thrown after 
> that. Such behavior prevents the caller, for instance, a `URLClassLoader`, 
> from closing a Jar file.
> 
> The proposed fix checks if entry exists before caching a Jar file (only for 
> cases with enabled caching):
> - If entry exists - jar file is cached if it wasn't cached before
> - If entry doesn't exist and jar file wasn't cached before - jar file is 
> closed and exception is thrown
> - If entry doesn't exist and jar file was cached before - jar file is kept 
> cached and exception is thrown
> 
> 
> The following tests have been used to verify the fix:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests

Hi Aleksei, thanks for putting this together.

`test/jdk/sun/misc/URLClassPath/RemoveJar.java` seems to be an older version of 
`test/jdk/java/net/URLClassLoader/RemoveJar.java`. The two tests are almost 
identical - so `test/jdk/sun/misc/URLClassPath/RemoveJar.java` can probably be 
removed from the PR.

Otherwise the proposed changes look good to me.

-

PR: https://git.openjdk.java.net/jdk/pull/3263

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

[Alan Bateman]

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson  wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more 
>> information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one 
>> Review.
>
> Stefan Karlsson has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Review Alan

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

[Stefan Karlsson]

On Wed, 31 Mar 2021 09:29:43 GMT, Alan Bateman  wrote:

>> Stefan Karlsson has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Review Alan
>
> test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:
> 
>> 27:  * @summary BufferedInputStream calculates negative array size with large
>> 28:  *  streams and mark
>> 29:  * @run main/othervm -Xmx4G -Xlog:gc,gc+heap,gc+ergo+heap 
>> -XX:+CrashOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions 
>> -XX:+G1ExitOnExpansionFailure LargeCopyWithMark
> 
> Looks okay but I assume you can split this line to avoid having a 170+ line 
> in this file, this helps with future side-by-side review.

Thanks. I've added line breaks to make it easier to read.

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]

[Stefan Karlsson]

> Add more logging to the LargeCopyWithMark.java test, to gather more 
> information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one 
> Review.

Stefan Karlsson has updated the pull request incrementally with one additional 
commit since the last revision:

  Review Alan

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3282/files
  - new: https://git.openjdk.java.net/jdk/pull/3282/files/a7260c86..1828df10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3282=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3282=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282

PR: https://git.openjdk.java.net/jdk/pull/3282

Withdrawn: 8264397: Use the blessed modifier order in jdk.incubator.foreign

[Alex Blewitt]

On Mon, 29 Mar 2021 21:09:56 GMT, Alex Blewitt 
 wrote:

> 8264397: Use the blessed modifier order in jdk.incubator.foreign

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/3253

Re: RFR: 8264397: Use the blessed modifier order in jdk.incubator.foreign

[Alex Blewitt]

On Tue, 30 Mar 2021 21:26:34 GMT, Alex Blewitt 
 wrote:

>> Hi @alblue, thanks for the contribution. We will make sure to integrate this 
>> at some point, but I don't think now is the right moment to do this kind of 
>> stylistic changes to the API/implementation. If you want to integrate the 
>> fix now, I'd suggest to file a PR against 
>> https://github.com/openjdk/panama-foreign, and we'll be happy to sponsor the 
>> change. That way you'd be guaranteed the change would be included in the 
>> next incubation round.
>
> Have submitted change to the panama-foreign branch; let me know if that's the 
> appropriate place and I can abandon this PR.

Going to upstream this patch into opendjk/panama-foreign

-

PR: https://git.openjdk.java.net/jdk/pull/3253

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

[Alan Bateman]

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson  wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more 
> information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one 
> Review.

test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:

> 27:  * @summary BufferedInputStream calculates negative array size with large
> 28:  *  streams and mark
> 29:  * @run main/othervm -Xmx4G -Xlog:gc,gc+heap,gc+ergo+heap 
> -XX:+CrashOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions 
> -XX:+G1ExitOnExpansionFailure LargeCopyWithMark

Looks okay but I assume you can split this line to avoid having a 170+ line in 
this file, this helps with future side-by-side review.

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: Proposal for Decimal64 and Decimal128 value-based classes

[Stephen Colebourne]

On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore
 wrote:
> There are also other interesting types to be explored in that domain,
> such as Long128, LongDouble (extended precision float) and HalfFloats.

Perhaps it would be beneficial to have a GitHub repo where designs for
these could be fleshed out. Kind of like a JSR would do. (For example,
Valhalla and OopenJDK will need to agree on naming conventions for the
various methods - for example I prefer plus() but others prefer add().
Stephen

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

[Stefan Karlsson]

On Wed, 31 Mar 2021 08:39:02 GMT, Kim Barrett  wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more 
>> information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one 
>> Review.
>
> Looks good, and trivial.

Thanks Kim!

-

PR: https://git.openjdk.java.net/jdk/pull/3282

Re: RFR: 8264489: Add more logging to LargeCopyWithMark.java

[Kim Barrett]

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson  wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more 
> information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one 
> Review.

Looks good, and trivial.

-

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3282

RFR: 8264489: Add more logging to LargeCopyWithMark.java

[Stefan Karlsson]

Add more logging to the LargeCopyWithMark.java test, to gather more information 
when this test fails with OOME. 

The intention is to gather more info for JDK-8239089.

I consider this patch trivial, and expect to push it after I've gotten on 
Review.

-

Commit messages:
 - 8264489: Add more logging to LargeCopyWithMark.java

Changes: https://git.openjdk.java.net/jdk/pull/3282/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3282=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264489
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282

PR: https://git.openjdk.java.net/jdk/pull/3282