On Tue, 5 Jan 2021 01:03:55 GMT, Sandhya Viswanathan
wrote:
> Vector conversion with part > 0 is implemented using slice(origin, vector)
> instead of slice(origin).
> The slice(origin) has intrinsic implementation whereas slice(origin, vector)
> doesn’t.
> Slice(origin) is written using vector
> On Dec 16, 2020, at 1:47 AM, Chris Hegarty wrote:
>
> On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov
> wrote:
>
>>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>>> java.base
>>
>> Andrey Turbanov has updated the pull request incrementally with one
>> addi
On Sat, 12 Dec 2020 18:40:16 GMT, Joe Darcy wrote:
> Given upcoming changes in the JLS terminology around the term "type", various
> sections were renamed:
>
>
> https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
>
> The @jls tags in the java.base modu
On Fri, 11 Dec 2020 19:29:09 GMT, Mandy Chung wrote:
>> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
>> classes with RecordComponents attributes.
>>
>> See the discussion at
>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html
>
On Tue, 8 Dec 2020 06:14:35 GMT, Stuart Marks wrote:
>> This rewrites the doc of ArraysSupport.newLength, adds detail to the
>> exception message, and adds a test. In addition to some renaming and a bit
>> of refactoring of the actual code, I also made two changes of substance to
>> the code:
On Tue, 1 Dec 2020 20:36:48 GMT, Paul Sandoz wrote:
> Float/DoubleVector implementations contain redundant cases for bitwise
> operations. Such bitwise operations will fail on such FP vectors before the
> case is reached.
This pull request has now been integrated.
Changeset: cfd070
Float/DoubleVector implementations contain redundant cases for bitwise
operations. Such bitwise operations will fail on such FP vectors before the
case is reached.
-
Commit messages:
- 8257537: [vector] Cleanup redundant bitwise cases on floating point vectors
Changes: https://git
On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov wrote:
> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
>
> Testing: tier1-4
Marked as reviewed by psandoz (Reviewer).
-
PR: https://git.openjdk.ja
On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote:
> Concurrent updates may lead to redundant LambdaForms created and unnecessary
> class loading when those are compiled.
>
> Most notably, it severely affects MethodHandle customization: when a
> MethodHandle is called from multiple thre
On Tue, 24 Nov 2020 07:10:14 GMT, Stuart Marks wrote:
>> This change introduces a new terminal operation on Stream. This looks like a
>> convenience method for Stream.collect(Collectors.toList()) or
>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>> method directl
On Thu, 19 Nov 2020 19:47:15 GMT, Sandhya Viswanathan
wrote:
>> Remove partially implemented in-place conversion vector operators from
>> Vector API:
>>ofNarrowing, ofWidening, INPLACE_XXX
>
> Sandhya Viswanathan has updated the pull request incrementally with one
> additional commit since
On Thu, 19 Nov 2020 03:26:20 GMT, Sandhya Viswanathan
wrote:
> Remove partially implemented in-place conversion vector operators from Vector
> API:
>ofNarrowing, ofWidening, INPLACE_XXX
The documentation `Vector.convert` and `Vector.convertShape` needs to be
updated to remove specificatio
On Thu, 19 Nov 2020 01:07:12 GMT, Paul Sandoz wrote:
> Refactor the vector conversions tests to improve performance and reduce
> explicit test methods (using data providers).
This pull request has now been integrated.
Changeset: 580f22cc
Author: Paul Sandoz
URL:
Refactor the vector conversions tests to improve performance and reduce
explicit test methods (using data providers).
-
Commit messages:
- 8256581: Refactor vector conversion tests
Changes: https://git.openjdk.java.net/jdk/pull/1302/files
Webrev: https://webrevs.openjdk.java.net/?
On Wed, 18 Nov 2020 00:50:22 GMT, Mandy Chung wrote:
>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
>> objects
>> be shared between a hidden class and other classes. A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>>
>
On Tue, 17 Nov 2020 23:34:23 GMT, Stuart Marks wrote:
>> Added a cast in the right place, thanks to @jonathan-gibbons.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the last revision:
>
> cast to double instead of Object
Marked as reviewed by
On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> Jim Laskey has up
On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks wrote:
> Added a cast in the right place, thanks to @jonathan-gibbons.
test/jdk/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java
line 69:
> 67: assertEquals(list.size(), array.length);
> 68: for (int i = 0;
On Fri, 6 Nov 2020 02:50:29 GMT, Stuart Marks wrote:
>> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/ToListOpTest.java
>> line 73:
>>
>>> 71: }
>>> 72:
>>> 73: @Test(dataProvider = "withNull:StreamTestData",
>>> dataProviderClass = StreamTestDataProvider.class)
>>
On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote:
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on
On Fri, 30 Oct 2020 16:17:06 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can
On Thu, 29 Oct 2020 18:14:05 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can
On Mon, 26 Oct 2020 16:13:59 GMT, Paul Sandoz wrote:
>> I've updated the javadoc, and added two benchmarks that show the existing
>> discrepancy between an exact and a generic use of a VarHandle, as well as
>> showing that an exact VarHandle is as fast as a generic Var
On Mon, 26 Oct 2020 13:37:58 GMT, Jorn Vernee wrote:
>> @PaulSandoz I've implemented your suggestion, by moving the `exact` flag to
>> VarHandle itself. FWIW, the VH::accessModeType method took an AccessMode
>> value as an argument, and the AccessDescriptor only stored the ordinal, so I
>> add
On Fri, 23 Oct 2020 18:06:51 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can
On Thu, 22 Oct 2020 14:26:37 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java
>> line 120:
>>
>>> 118: }
>>> 119: }
>>> 120: throw new AssertionError("Cannot get here!");
>>
>> This
On Thu, 22 Oct 2020 14:31:12 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36:
>>
>>> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError;
>>> 35:
>>> 36: /** TODO */
>>
>> Is the TODO to make this class public later an
On Thu, 22 Oct 2020 13:30:13 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
>> line 126:
>>
>>> 124: *
>>> 125: * @param symbol downcall symbol.
>>> 126: * @param type the method type.
>>
>> s/method type/carr
On Wed, 21 Oct 2020 20:17:32 GMT, Sandhya Viswanathan
wrote:
> Additional tests to increase Vector API public method code coverage to > 99%.
I already reviewed these test updates when integrated into the
`vectorIntrinsics` branch of the `panama-vector` repository.
-
Marked as rev
On Mon, 19 Oct 2020 19:43:13 GMT, Paul Sandoz wrote:
> The zero methods on `IntVector` and all other specializations are missing
> documentation.
This pull request has now been integrated.
Changeset: 60d3fa2e
Author: Paul Sandoz
URL: https://git.openjdk.java.net/jdk/commit/60
> The zero methods on `IntVector` and all other specializations are missing
> documentation.
Paul Sandoz has updated the pull request incrementally with one additional
commit since the last revision:
Address CSR review.
-
Changes:
- all: https://git.openjdk.java.net/jd
gt;>
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main
>> architects of all the hotspot changes you see here, and without their help,
>> the foreign linker support wouldn't be what it is today. As usual, a big
>> thank to Paul Sandoz, who provided
gt;>
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main
>> architects of all the hotspot changes you see here, and without their help,
>> the foreign linker support wouldn't be what it is today. As usual, a big
>> thank to Paul Sandoz, who provided
On Thu, 15 Oct 2020 17:58:29 GMT, CoreyAshford
wrote:
>> Please update
>> [compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
>> and add the intrinsic signature.
>
>> Please update
>> [compiler/graalunit/Hotspo
On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz wrote:
> Minor updates, with no specification changes, to the documentation of Vector
> API.
>
> The compilation of the Vector module was updated to turn on doclint errors
> for >= protected documentation.
This pull re
The zero methods on `IntVector` and all other specializations are missing
documentation.
-
Commit messages:
- 8255022: Documentation missing for Vector API zero methods
Changes: https://git.openjdk.java.net/jdk/pull/748/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7
Minor updates, with no specification changes, to the documentation of Vector
API.
The compilation of the Vector module was updated to turn on doclint errors for
>= protected documentation.
-
Commit messages:
- 8255020:Minor updates to docs jdk.incubator.vector
Changes: https://gi
On Wed, 14 Oct 2020 21:29:55 GMT, CoreyAshford
wrote:
>> Hi Corey,
>>
>>> Are you thinking of a case where that produces a higher iteration count?
>> Sorry for the confusion. This is also fine:
>> length = sl - sp - 12
>> i = length / block_size
>> if (i <= 0) return 0
>>
>> But I still wonder
On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote:
> This pull request is for integration of the Vector API. It was previously
> reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here
> (searching for issue numbe
d directly, once the
> CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the
> final review and this pull request no code
> has changed, except for that related to merging.
Paul Sandoz has updated the pull request with a new ta
d directly, once the
> CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the
> final review and this pull request no code
> has changed, except for that related to merging.
Paul Sandoz has updated the pull request with a new ta
d directly, once the
> CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the
> final review and this pull request no code
> has changed, except for that related to merging.
Paul Sandoz has updated the pull request with a new ta
d directly, once the
> CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the
> final review and this pull request no code
> has changed, except for that related to merging.
Paul Sandoz has updated the pull request incrementally
On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarreño
wrote:
> * Release fence guarantees that cacheArray field will published with a
> non-null value.
> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>
> This is a follow up to @PaulSandoz's feedback
> [here](https://m
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change `@sinc
Hi Sergey,
Unsafe.allocateUninitializedArray should be used with great care, so as we are
confident that no array, covering uninitialized memory, leaks out. Or later we
unintentionally introduce a problem through refactoring.
The update to AbstractStringBuilder is problematic because the unini
If memory serves me correctly we added these methods for completeness when
doing VarHandles, but we deferred any intrinsic work (do it when really needed).
This looks good to me. Minor tweak. I would recommend using an @implNote to be
clear this not permanent behavior and could change e.g.:
* @
Hi Roger,
A nice minimal addition. I agree with Mark’s naming suggestion.
- Use appropriate code convention for static field names.
- The encoder comes with two encoding production signatures, that returning a
String and that for encoding into a StringBuilder.
The decoder comes with just one su
Yes. Core library code close to the JVM in OpenJDK (that in the java.base
module, commonly that in java.lang.* close to that in hotspot) often assumes
implementation specifics of the JVM. The two are closely coupled. There are
other such implementation-specific contracts like @Stable, or “final
Hi Galder,
Thanks for doing the fix and the work verifying.
I also verified using a fence fixes the jcstress test. Similarly, I found I
could only reproduce the issue in HotSpot when running a test more like
ClassValue (the double checked locking pattern when publishing to a plan field)
with t
Hi Patrick,
This looks good. To resolve the ambiguity of when results are undefined I
suggest we tweak the docs at the various locations, see below. No need for
another round of review.
I can understand the desire to place the primitive functional interfaces in
j.u.functions, but for reasons p
+1
Paul.
> On Aug 17, 2020, at 1:01 PM, Vicente Romero wrote:
>
> Please review this very simple fix for [1] at [2]. The fix is a very simple
> one liner change,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8246804
> [2] http://cr.openjdk.java.net/~vromero/8246804/we
Hi Tagir,
Clearly I am a terribly tracker of null values! My apologies for the poor
review of that.
Regarding changing sub-map computeIfAbsent and compute behavior, yes that would
require a CSR.
Thinking more about this, it may be better to play it safe and retain the
current behavior for thi
Here’s some pertinent information from Doug’s excellent document of memory
order modes [1]:
"As a delicate (but commonly exploited) special case of the above
considerations, acquire-style reads of immutable fields of newly constructed
objects do not require an explicit fence or moded access --
Hi David,
This is subtle. ClassValue extends from WeakHashMap that has a few final
fields. In such cases, for HotSpot at least, the compiler will place fence
between the stores to the fields of ClassValue and the store to publish in the
field of Class. So it should not be possible to observe a
Hi Tagir,
The implementations are simple, but as you noted there is some subtle behavior
in reporting the key-out-of-range exception.
Changes to the tests look good.
The putIfAbsent and merge implementations result in a change of behavior. For
putIfAbsent, a key out-of-range now results in an
Hi Tagir,
Thanks for your measured patience. I will take a look.
Paul.
> On Jul 26, 2020, at 9:04 AM, Tagir Valeev wrote:
>
> Hello!
>
> A gentle ping: please review
> https://bugs.openjdk.java.net/browse/JDK-8244288
> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
> The details are l
+1
Paul.
> On Jul 23, 2020, at 2:24 PM, Joe Darcy wrote:
>
> Hello,
>
> One class in the javax.script package uses a default constructor; please
> review the patch below and CSR
> (https://bugs.openjdk.java.net/browse/JDK-8250239) to replace it with an
> explicit constructor.
>
> Thanks,
>
860.html>
> On Jul 13, 2020, at 11:01 AM, Chris Hegarty wrote:
>
>>
>> On 1 Apr 2020, at 23:46, Paul Sandoz > <mailto:paul.san...@oracle.com>> wrote:
>>
>> Hi,
>>
>> A prior email sent out a request for review of the Vector API in p
hile mapMulti uses a push API.
>
> so having mapMulti and flatMap doing cancellation differently is inconsistent.
>
> Consistency is a good way to avoid to expect that all operations do
> short-circuiting optimizations.
>
> Rémi
>
> - Mail original -
>> De:
Hi Peter,
You guessed correctly about the motivation from the API perspective.
I would like to stress that short-circuiting optimizations are an
implementation detail that are only partially applied. Surfacing the notion of
cooperative cancellation for one operation has quite a cost, and will l
Hiding is a misleading characterization. It’s about reducing the API surface of
this feature for reasons previously mentioned. I am reluctant to impose
ObjIntConsumer vs. IntObjConsumer on developers.
Paul.
> On Jul 2, 2020, at 12:36 PM, fo...@univ-mlv.fr wrote:
>
>
> The rational is that th
Hi Remi,
This was my suggestion not Brian’s. I proposed to place these interfaces in the
current location, likely to be renamed in accordance with the operation name,
when that settles.
The rational is that they will fade away in unison with Int/*/Stream when
generic specialization becomes ava
Hi,
We traded CPS style for reusing existing functional interfaces. Originally the
signature (my first choice) was as you indicate.
By chance it just so happens that the current signature is the same shape as
that for the accumulating argument type of the three arg collect terminal
operation:
Looks good, some very minor comment (no need for another round).
MemoryLayout.java
—
146 * That is, the above declaration is identical to the following, more
verbose one:
147 * {@code
148 MemoryLayout taggedValuesWithHole = MemoryLayout.ofSequence(5,
149 MemoryLayout.ofStruct(
150
Mode Cnt ScoreError Units
>> BulkOps.mismatch_large_bytebuffer avgt 30 88266.728 ? 4083.476 ns/op
>> BulkOps.mismatch_large_segment avgt 30 86141.343 ? 2450.450 ns/op
>> BulkOps.mismatch_small_bytebuffer avgt 30 6.360 ? 0.425 ns/op
>> BulkOps.mismat
Thanks Chris.
> On Jun 18, 2020, at 2:57 AM, Maurizio Cimadamore
> wrote:
>
> Thanks for looking at this Chris
>
> On 17/06/2020 21:56, Paul Sandoz wrote:
>> Hi Chris,
>>
>> AbstractMemorySegmentImpl
>> —
>>
>> In vectorizedMismatchLar
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
> 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;
&g
> On Jun 16, 2020, at 3:36 PM, Peter Levart wrote:
>
> Yes, or even better: MethodHandles.empty(MethodType.methodType(pClass,
> byte[].class, Object[].class)) which was suggested by Johanes Kuhn as here:
>
>
> http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.02/
>
Looks good.
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 = s1;
If (s != null) {
if (s.isEmpty()) {
Hi Peter,
199 private Map deserializationCtrs;
Change to be either ConcurrentMap or ConcurrentHashMap, thereby making it
clearer when using.
2679 private static MethodHandle defaultValueExtractorFor(Class
pType) {
Can the implementation use MethodHandles,zero? e.g.
return Met
s}
> * to be initialized if it has not been already initialized,
> * as specified in JVMS {@jvms 5.5}.
>
LGTM,
Paul.
> There are detailed rules about class initialization in JVMS 5.5.
>
> Mandy
>
> On 6/4/20 12:13 PM, Paul Sandoz wrote:
>> Hi Mand
Hi Mandy,
What about this case:
class Test {
static {
MethodHandles.lookup().ensureClassInitialized(Test.class);
// not yet initialized
}
}
(I see you do that for m/p1/A.java and Test.clinitInvokeEnsureClassInitialized.)
Do we need mention this in the spec? e.g. this method does not
> On Jun 4, 2020, at 11:43 AM, Alan Bateman wrote:
>
> On 04/06/2020 17:55, Paul Sandoz wrote:
>> :
>> FWIW I keep tripping over the prefix “ensures”. As I understand the
>> implementation initializes a class, if not already so (and it has to check
>> as
> On Jun 3, 2020, at 7:31 PM, Mandy Chung wrote:
>
>
>
> On 6/3/20 5:16 PM, Paul Sandoz wrote:
>> Hi Mandy,
>>
>> Did you consider an alternative name, such as:
>>
>> /**
>> * Initializes {@code targetClass}, if not already initializ
Hi Mandy,
Did you consider an alternative name, such as:
/**
* Initializes {@code targetClass}, if not already initialized.
* ...
*/
public Class initializeClass(Class targetClass) ...
?
What about the companion Unsafe.shouldBeInitialized? I have seen (and written)
code like this:
if (UNS
It’s tempting to go all out and investigate the deprecation of (not for
removal) ThreadGroup in its entirety, and also deprecate the Thread
constructors accepting ThreadGroup, related methods in SecurityManager, etc. I
suspect that’s probably more work than you want to take on right now, and may
+1
Paul.
> On Jun 2, 2020, at 6:21 AM, Jim Laskey wrote:
>
> Revised with requested changes.
>
>
> http://cr.openjdk.java.net/~jlaskey/8230743/webrev-01
> <http://cr.openjdk.java.net/~jlaskey/8230743/webrev-01>
>
>
>> On Jun 1, 2020, at 5:32 PM, Pau
> On Jun 1, 2020, at 12:44 PM, Jim Laskey wrote:
>
>
>
>> On Jun 1, 2020, at 4:28 PM, Paul Sandoz wrote:
>>
>> Can we consolidate the use of Integer.MAX_VALUE - 8 in tests by referring to
>> the constant jdk.internal.util.ArraysSupport.MAX_ARRAY_LENG
Oh, so easy to miss. Better yet use TestNG's Assert.fail, or for simple cases
declare the expected exception as an argument of the test annotation.
Paul.
> On Jun 1, 2020, at 12:39 PM, Martin Buchholz wrote:
>
> Missing "throw"; We should have an assertThrows test method (many
> people have wr
Can we consolidate the use of Integer.MAX_VALUE - 8 in tests by referring to
the constant jdk.internal.util.ArraysSupport.MAX_ARRAY_LENGTH?
StringJoiner.java
—
164 @Override
165 public String toString() {
166 final String[] elts = this.elts;
167 if (elts == null && e
+1
I quibble about the “ignored” variable name for the caught ArithmeticException.
Paul.
> On Jun 1, 2020, at 5:48 AM, Jim Laskey wrote:
>
> Cleans up every case of OutOfMemoryError without a message. Some logic
> changes in String::repeat and ByteArrayChannel:: hugeCapacity.
>
> Thank you.
Looks good. I sent some trivial comments offline.
Paul.
> On Jun 1, 2020, at 4:07 AM, Claes Redestad wrote:
>
> Hi,
>
> the LambdaFormEditor uses a SoftReference-based cache to avoid
> generating LambdaForms we have already generated. By introducing a
> lookup key that is not a SoftReference w
This looks good.
204 String recipe = "\u0001".repeat(concatType.parameterCount());
IIUC, that’s a rather convoluted way of creating a List from:
Collections.nCopies(concatType.parameterCount(). (String) null);
Perhaps it makes sense to double down on the List representation with an
+1 (reviewed on panama-dev)
Paul.
> On May 28, 2020, at 2:25 PM, Maurizio Cimadamore
> wrote:
>
> Hi,
> this followup change includes a number of tweaks that have been added to the
> memory access API while we were in the process of integrating it. Most of
> them have been contributed by Chr
+1
Paul.
> On May 29, 2020, at 2:04 AM, Conor Cleary wrote:
>
> Hi,
>
> The method-level documentation of Intstream::reduce(int, IntBinaryOperator)
> mentions the average function as a case of reduction even though the function
> cannot be used with the reduce method. This might cause confus
+1 (previously reviewed on the panama-dev list)
It’s very pleasing to see this get simplified through some good collaboration.
StampedLock is quite powerful, and likely an under utilized resource.
Paul.
> On May 28, 2020, at 4:20 AM, Maurizio Cimadamore
> wrote:
>
> Hi,
> during the review o
That’s rather elegant. Nicely done.
Paul.
> On May 27, 2020, at 8:50 AM, Claes Redestad wrote:
>
> Hi Rémi,
>
> thanks for looking at this.
>
> On 2020-05-27 17:12, Remi Forax wrote:
>> Hi Claes,
>> so instead of having a prefix and a suffix, there is only a prefix, a suffix
>> being seen as
Looks good.
Paul.
> On May 27, 2020, at 5:54 AM, Claes Redestad wrote:
>
> Hi,
>
> Since JDK-8222852 the default String concat strategy aggressively folds
> string constants into prepender method handles, which means an
> expression like foo + bar and one like "x" + foo + "y" + bar + "z" will
I prefer the first revision from a simplicity perspective.
Are there any measurable benefits in the subsequent revision? It requires some
careful reading, where the logic in the prepender is duplicated in the layering
of the computeIfAbsent functions. Which, if needed, is fine.
Are the existin
> On May 22, 2020, at 10:40 AM, Andrew Haley wrote:
>
> On 5/22/20 5:12 PM, Paul Sandoz wrote:
>
>> I am not terribly familiar with the AArch64 code, but I would note
>> the Vector API comes with a bunch of unit tests should exercise the
>> code gen, just no
Hi,
I support the removal of all the other strategies to simplify SCF and make it
more maintainable.
Having one or more strategies to fall back on (with an undocumented flag) was I
think right thing to do when initially introducing the feature. Over time, the
default strategy has become more a
HI Andrew,
Thanks for looking.
I am not terribly familiar with the AArch64 code, but I would note the Vector
API comes with a bunch of unit tests should exercise the code gen, just not as
directly as I presume you would like.
To what extent do you feel we can follow up with additional issues
compiler flags (like -Xcomp).
>
> -katya
>
>
> On 5/19/20 3:25 PM, Paul Sandoz wrote:
>> I just realized that the vector tests have not been included in any JDK test
>> category e.g. tier1.
>> Ordinarily I would expect the tests to be added to tier1 since the tests
>&g
+1
Paul.
> On May 20, 2020, at 7:01 AM, Maurizio Cimadamore
> wrote:
>
> Another very small iteration which fixes a gap in the javadoc specification
> for MemorySegment::toArray (thanks Chris!)
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev
>
> Delta webrev:
>
>
tier to potentially reduce the cost of
testing.
Advice very much appreciate on which tier the tests should belong to.
Paul.
> On May 18, 2020, at 12:13 PM, Paul Sandoz wrote:
>
> HI,
>
> Here’s an update of the API and implementation webrevs based on (mostly) API
> feedback. W
+1
Paul.
> On May 19, 2020, at 1:00 PM, Jim Laskey wrote:
>
> Please review this change to remove the preview heading from the javadoc of
> String::formatted. This also updates the @since to 15.
>
> Thank you.
>
> Cheers,
>
> -- Jim
>
>
> csr: https://bugs.openjdk.java.net/browse/JDK-82453
+1
Originally I thought this was a lost cause or too much effort given the edge
case, but your prior fix and Peter’s nudging to “lazy” static values made it
more viable.
I agree with not changing the other strategies. Let's remove ‘em.
Paul.
> On May 19, 2020, at 6:59 AM, Claes Redestad wrot
-38dd763d023e-2020-05-15-88a83f7238d8/webrev/>
> On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote:
>
> Hi,
>
> A prior email sent out a request for review of the Vector API in preparation
> for JEP 338: Vector API (Incubator) [1] to be proposed for target:
>
> https://mail.op
301 - 400 of 2576 matches
Mail list logo
