Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

[kabutz]

On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes  wrote:

>> kabutz has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type absolutely **must** be 
> opt-in. There are simply far too many side-effects of using the FJP and 
> multiple threads to perform the calculation in parallel as if it is just a 
> minor implementation detail. A clear API is 1000x better than a "kill switch".
> 
> And yes you may still need to expose some kind of tuning knob.
> 
> David

> > Hi @dholmes-ora thanks - is it possible for me to create a CSR without 
> > having access to JIRA? Or do I need to find a sponsor who can help do this 
> > on my behalf?
> 
> You will need a sponsor to do this for you. I'm a little surprised after all 
> these years that you've never even gotten Author role. :)

Most of my contributions have been finding bugs, rather than fixing them. It's 
only recently that I've started adding code to the OpenJDK. So, I'm not 
surprised at all.

-

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

Re: RFR: 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories [v2]

[Jaikiran Pai]

On 26/11/21 7:32 am, Mandy Chung wrote:

On Thu, 25 Nov 2021 02:22:20 GMT, Jaikiran Pai  wrote:


Mandy Chung has updated the pull request incrementally with one additional 
commit since the last revision:

   minor fix to avoid casting

Hello Mandy, one small issue - `ClassFileReader`, `DependencyFinder` and 
`VersionHelper` are misisng a copyright year update for this change.

@jaikiran Sorry, I missed your comment about the copyright year update.  I will 
update them in other jdeps fix.


That sounds fine, Mandy. Thank you.

-Jaikiran

Re: RFR: 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories [v2]

[Mandy Chung]

On Thu, 25 Nov 2021 02:22:20 GMT, Jaikiran Pai  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   minor fix to avoid casting
>
> Hello Mandy, one small issue - `ClassFileReader`, `DependencyFinder` and 
> `VersionHelper` are misisng a copyright year update for this change.

@jaikiran Sorry, I missed your comment about the copyright year update.  I will 
update them in other jdeps fix.

-

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

Integrated: 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories

[Mandy Chung]

On Tue, 23 Nov 2021 20:54:55 GMT, Mandy Chung  wrote:

> jdeps intends to report an error if there are multiple versions of the same 
> class being parsed.   module-info.class should be excluded from such 
> detection.
> 
> This patch also fixes a data race in `VersionHelper::set` and also unwraps 
> the `ExecutionException` when FutureTask of parsing the classes throws an 
> exception to report `MultiReleaseException` properly.

This pull request has now been integrated.

Changeset: 7e54d065
Author:Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/7e54d065a17f1277adf1b8561fadb8a480bc6bed
Stats: 301 lines in 11 files changed: 288 ins; 6 del; 7 mod

8277165: jdeps --multi-release --print-module-deps fails if module-info.class 
in different versioned directories
8277166: Data race in jdeps VersionHelper
8277123: jdeps does not report some exceptions correctly

Reviewed-by: jvernee, alanb

-

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

Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs

[Nick Gasson]

On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

Marked as reviewed by ngasson (Reviewer).

-

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

Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs

[Ningsheng Jian]

On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

Looks good to me.

-

Marked as reviewed by njian (Committer).

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

RFR: JDK-8277795: ldap connection timeout not honoured under contention

[Rob McKenna]

This fix attemps to resolve an issue where threads can stack up on each other 
while waiting to get a connection from the ldap pool to an unreachable server. 
It does this by having each thread start a countdown prior to holding the 
pools' lock. (which has been changed to a ReentrantLock) Once the lock has been 
grabbed, the timeout is adjusted to take the waiting time into account and the 
process of getting a connection from the pool or creating a new one commences.

Note: this fix also changes the meaning of the connection pools initSize 
somewhat. In a situation where we have a large initSize and a small timeout the 
first thread could actually exhaust the timeout before creating all of its 
initial connections. Instead this fix simply creates a single connection per 
pool-connection-request. It continues to do so for subsequent requests 
regardless of whether an existing unused connection is available in the pool 
until initSize is exhausted. As such it may require a CSR.

-

Commit messages:
 - JDK-8277795: formatting
 - JDK-8277795: whitespace cleanup
 - JDK-8277795: ldap connection timeout not honoured under contention

Changes: https://git.openjdk.java.net/jdk/pull/6568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6568=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277795
  Stats: 318 lines in 4 files changed: 175 ins; 72 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6568/head:pull/6568

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

Re: Adding an @Immutable annotation to Java

[Alan Snyder]

I like the idea of an @Immutable annotation. So much so, that I have created 
one and use it heavily.
However, my @Immutable is just for documentation; it does not have a rigorous 
semantics that would be
needed for a compiler to validate its use or generate different code.
But it could be used by lint-like tools to warn against suspicious code.

My @Immutable applies only to classes and interfaces, not variables or type 
parameters.
A class or interface is either @Immutable or it is not.
That avoids much complexity.

I think it is fine to have an @Immutable list (type) whose elements are mutable.
Is an instance of an immutable list with mutable elements immutable or not?
Tell me why you want to know and I might be able to answer the question.

I also think there are cases where an @Immutable type might have a mutable 
implementation
(in other words, it might have instance variables that are not final or have 
non-immutable types).
Examples include internal caching and configurability of performance or 
incidental behavior such as logging.

In general, immutability is in the mind of the beholder.

A case can be made that an interface or class that is @Immutable should only 
permit
extensions and implementing classes that are @Immutable.
Perhaps a compiler could validate that, but only at compilation time
(to ensure binary compatibility when an @Immutable annotation is added to an 
existing class or interface).

The idea of the compiler trying to enforce a semantics of immutability is scary.
Java tried to do this with uninitialized and final instance variables, and the 
result has been a disaster.
The rules make semantically valid code illegal, forcing complex workarounds.
(For example, suppose you want to compute a value, bind it to a final instance 
variable, and pass it to the superclass constructor.)
Yet it is still possible, actually quite easy, to write code that accesses 
uninitialized final variables.
I have code that checks a final @NotNull instance variable to ensure that it is 
not null.
IDEA tells me the check is unnecessary, but IDEA is wrong.

Immutability is a much more complicated concept than uninitialized.
Not something the compiler should mess with.

  Alan



> On Nov 25, 2021, at 10:10 AM, Ralph Goers  wrote:
> 
> I would think that if a class is marked immutable that would imply all the 
> fields in it and from its inherited 
> classes should be immutable. If fields are marked immutable then it would 
> only apply to them.
> 
> What I wonder is what its relationship to final would be. The final 
> annotation implies that a field must be 
> set in the constructor and cannot be modified after that. I would imagine 
> that @immutable to have to imply 
> @final but would also apply at runtime. For example, where declaring a List 
> field as final means you cannot 
> replace the List once it is set. I would expect @Immutable to do the same but 
> also mean that you cannot 
> add elements to the List through that reference. But that would also mean 
> that you cannot pass the reference 
> to another variable that isn’t also annotated with @Immutable - unless the 
> immutable attribute becomes some 
> kind of internal flag on the object.
> 
> To be clear, this concept is always something I have wanted in Java. It is a 
> real pain to have to do things like
> List list = Collections.unmodifiableList(List.of(“foo”, “bar”));
> 
> Instead, it would be nice to be able to do
> @Immutable List list = List.of(“foo”, “bar”);
> 
> Although the two could be implemented to do the same thing, the second could 
> prevent passing the field in a 
> parameter that wasn’t declared @Immutable. Likewise, passing a non-immutable 
> list in a parameter annotated 
> with @Immutable could cause the list to be copied to an immutable list 
> automatically.
> 
> Ralph
> 
>> On Nov 25, 2021, at 2:49 AM, Mariell Hoversholm  
>> wrote:
>> 
>> On Thu, 25 Nov 2021 at 10:03, Andrew Haley 
>> wrote:
>> 
 Quick question, out of curiosity: how would it behave with respect to
 inheritance? Can a @Immutable class inherit from an non immutable one?
>>> 
>>> And: does @Immutable mean deeply immutable? IMO it really should,
>>> but that's harder to check, and we'd have to think about what this
>>> means for binary compatibility.
>>> 
>> 
>> As cited in the original email,
>>> and the programmer could, for example, annotate a new record object with
>> @Immutable only if all its fields are annotated with @Immutable.
>> 
>> I would infer from this that it would mean deeply immutable.
>> To clarify further, the following record `Wrapper` would be legal only
>> because `A` has `@Immutable` on its _type_:
>> 
>>   @Immutable class A {}
>>   @Immutable record Wrapper(A a) {}
>> 
>> while this would not be legal:
>> 
>>   class A {}
>>   @Immutable record Wrapper(A a) {}
>> 
>> because `A` is not `@Immutable`. This could however borrow from the Rust
>> concept of "auto-traits" (read: automatically apply certain traits or
>> 

Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

[David Holmes]

On 26/11/2021 4:15 am, kabutz wrote:

On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes  wrote:


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

   Removed JVM flags from benchmark


To add my 2c IMO a parallel version of this type absolutely **must** be opt-in. There are 
simply far too many side-effects of using the FJP and multiple threads to perform the 
calculation in parallel as if it is just a minor implementation detail. A clear API is 
1000x better than a "kill switch".

And yes you may still need to expose some kind of tuning knob.

David



@dholmes-ora has indicated that a [compatibility and 
specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is 
needed for this pull request. @kabutz please create a 
[CSR](https://wiki.openjdk.java.net/display/csr/Main) request for issue 
[JDK-8277175](https://bugs.openjdk.java.net/browse/JDK-8277175). This pull 
request cannot be integrated until the CSR request is approved.


Hi @dholmes-ora thanks - is it possible for me to create a CSR without having 
access to JIRA? Or do I need to find a sponsor who can help do this on my 
behalf?


You will need a sponsor to do this for you. I'm a little surprised after 
all these years that you've never even gotten Author role. :)


Cheers,
David


(Sorry for this newbie question)

-

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[John Neffenger]

On Thu, 25 Nov 2021 10:55:45 GMT, Andrew Leonard  wrote:

> Please consider providing a more general option, say `--date`, which takes an 
> [ISO 8601 date/time 
> string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).

The `jar` and `jmod` tools will need to truncate, restrict, or convert the time 
zone and fractional seconds permitted by the ISO 8601 date and time format.

The only way I found to store a timestamp using the methods of 
`java.util.zip.ZipEntry` that was independent of the system's time zone was by 
passing a local date and time in UTC to `setTimeLocal(LocalDateTime)`, 
truncated to seconds.

You can store a zoned date and time indirectly (in seconds) by adding an extra 
extended timestamp field to each entry with `setLastModifiedTime(FileTime)`. 
Unfortunately, that method also stores the "MS-DOS date and time" as the local 
date and time in the default time zone of the JVM (the time zone of the build 
machine). Furthermore, the extra field added to each entry increases the size 
of the archive.

The beauty of the `SOURCE_DATE_EPOCH` value is that it avoids any confusion in 
its interpretation while providing a straightforward solution to the only users 
ever known to need it.

-

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

Re: Adding an @Immutable annotation to Java

[Ralph Goers]

I would think that if a class is marked immutable that would imply all the 
fields in it and from its inherited 
classes should be immutable. If fields are marked immutable then it would only 
apply to them.

What I wonder is what its relationship to final would be. The final annotation 
implies that a field must be 
set in the constructor and cannot be modified after that. I would imagine that 
@immutable to have to imply 
@final but would also apply at runtime. For example, where declaring a List 
field as final means you cannot 
replace the List once it is set. I would expect @Immutable to do the same but 
also mean that you cannot 
add elements to the List through that reference. But that would also mean that 
you cannot pass the reference 
to another variable that isn’t also annotated with @Immutable - unless the 
immutable attribute becomes some 
kind of internal flag on the object.

To be clear, this concept is always something I have wanted in Java. It is a 
real pain to have to do things like
List list = Collections.unmodifiableList(List.of(“foo”, “bar”));

Instead, it would be nice to be able to do
@Immutable List list = List.of(“foo”, “bar”);

Although the two could be implemented to do the same thing, the second could 
prevent passing the field in a 
parameter that wasn’t declared @Immutable. Likewise, passing a non-immutable 
list in a parameter annotated 
with @Immutable could cause the list to be copied to an immutable list 
automatically.

Ralph

> On Nov 25, 2021, at 2:49 AM, Mariell Hoversholm  
> wrote:
> 
> On Thu, 25 Nov 2021 at 10:03, Andrew Haley 
> wrote:
> 
>>> Quick question, out of curiosity: how would it behave with respect to
>>> inheritance? Can a @Immutable class inherit from an non immutable one?
>> 
>> And: does @Immutable mean deeply immutable? IMO it really should,
>> but that's harder to check, and we'd have to think about what this
>> means for binary compatibility.
>> 
> 
> As cited in the original email,
>> and the programmer could, for example, annotate a new record object with
> @Immutable only if all its fields are annotated with @Immutable.
> 
> I would infer from this that it would mean deeply immutable.
> To clarify further, the following record `Wrapper` would be legal only
> because `A` has `@Immutable` on its _type_:
> 
>@Immutable class A {}
>@Immutable record Wrapper(A a) {}
> 
> while this would not be legal:
> 
>class A {}
>@Immutable record Wrapper(A a) {}
> 
> because `A` is not `@Immutable`. This could however borrow from the Rust
> concept of "auto-traits" (read: automatically apply certain traits or
> capabilities depending on how the type is defined), and infer `@Immutable`
> if it is deeply immutable, but that would raise the question of API &
> binary compatibility again.
> 
> It would also not be legal with this:
> 
>@Immutable
>class A {
>private int value;
>public void value(int value) { this.value = value; }
>}
> 
> because `value` is _not_ immutable.
> 
> Moving on from your question, this then poses the question of memoizing
> potentially very expensive optimisations, such as the following, currently
> found in the JDK:
> https://github.com/openjdk/jdk/blob/f0136ec94539d0e30ec11d44f8143196da1f7125/src/java.base/share/classes/java/lang/String.java#L2323-L2343
> Code above from `java.base/java.lang.String`:
> 
>public int hashCode() {
>// [snip large comment]
>int h = hash; // [hash is a property on the type]
>if (h == 0 && !hashIsZero) { // [hashIsZero is a property on the
> type]
>h = isLatin1() ? StringLatin1.hashCode(value)
>   : StringUTF16.hashCode(value);
>if (h == 0) {
>hashIsZero = true;
>} else {
>hash = h;
>}
>}
>return h;
>}
> 
> If the compiler / JRE were to infer the immutability from setters, it would
> again pose a new question of how to detect such. It could be possible that
> adding a new keyword or annotation to ignore mutable fields would be
> necessary (say `private mutable int hashCode;` as an example of my
> thoughts). At that point, however, what is the difference to not having
> this feature at all?
> 
> This is definitely an idea I like as a user of the language, but it's
> something that would require a bit of work, assuming it can be boiled down
> to something feasible at all.
> 
> -- 
> 
> *Mariell Hoversholm *(she/her)
> 
> Software Developer @ 
> 

Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

[kabutz]

On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes  wrote:

>> kabutz has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type absolutely **must** be 
> opt-in. There are simply far too many side-effects of using the FJP and 
> multiple threads to perform the calculation in parallel as if it is just a 
> minor implementation detail. A clear API is 1000x better than a "kill switch".
> 
> And yes you may still need to expose some kind of tuning knob.
> 
> David

> @dholmes-ora has indicated that a [compatibility and 
> specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request 
> is needed for this pull request. @kabutz please create a 
> [CSR](https://wiki.openjdk.java.net/display/csr/Main) request for issue 
> [JDK-8277175](https://bugs.openjdk.java.net/browse/JDK-8277175). This pull 
> request cannot be integrated until the CSR request is approved.

Hi @dholmes-ora thanks - is it possible for me to create a CSR without having 
access to JIRA? Or do I need to find a sponsor who can help do this on my 
behalf?

(Sorry for this newbie question)

-

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen  wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>
> test/jdk/tools/jar/JarEntryTime.java line 129:
> 
>> 127: // Make a jar file from that directory structure with
>> 128: // --source-date set to epoch seconds 1647302400 (15/03/2022)
>> 129: long sourceDate = 1647302400L;
> 
> Please consider  adding a few before Epoch test values.

@LanceAndersen java File times can't be before the epoch, but having a test 
before dostime 1980 would be useful

-

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

Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs

[Stuart Monteith]

On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

@nick-arm @nsjian Could you review, push this please?

-

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

Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs

[Evgeny Astigeevich]

On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

@stooart-mon Thank you for fixing the bug.
lgtm

-

Marked as reviewed by eas...@github.com (no known OpenJDK username).

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

Re: String.indexOf(single-char-String)

[Michael Bien]

Hello again,

I was trying to run JDK's benchmarks over night (second attempt 
actually) but had some difficulties to get stable results.


This makes it difficult to compare the modified version with a 
reference. I am not sure what the cause is, I have heard some intel CPUs 
can't run avx instructions for a long time without changing clock - 
maybe i am hitting this issue?
Its not the temperature and i turned boost and HT off + it runs in 
headless mode. One run already takes almost 5h and I have to run it 
twice - so i can't increase the iterations even more.



for example:

# Benchmark: 
org.openjdk.bench.java.lang.StringIndexOfChar.utf16_mixed_String

# Parameters: (loops = 10, pathCnt = 1000, rngSeed = 1999)

# Run progress: 95.35% complete, ETA 00:13:20
# Fork: 1 of 1
# Warmup Iteration   1: 18592.094 ns/op    <- second fastest run?
# Warmup Iteration   2: 20519.413 ns/op
# Warmup Iteration   3: 19768.099 ns/op
# Warmup Iteration   4: 23093.410 ns/op
# Warmup Iteration   5: 29112.909 ns/op
# Warmup Iteration   6: 18962.671 ns/op
# Warmup Iteration   7: 16721.933 ns/op    <- fastest run?
# Warmup Iteration   8: 20267.809 ns/op
# Warmup Iteration   9: 23934.031 ns/op
# Warmup Iteration  10: 22474.836 ns/op
# Warmup Iteration  11: 19583.471 ns/op
# Warmup Iteration  12: 19595.319 ns/op
# Warmup Iteration  13: 24865.299 ns/op
# Warmup Iteration  14: 19581.014 ns/op
# Warmup Iteration  15: 19566.849 ns/op
# Warmup Iteration  16: 19576.219 ns/op
# Warmup Iteration  17: 19574.475 ns/op
# Warmup Iteration  18: 19565.854 ns/op
# Warmup Iteration  19: 26594.867 ns/op
# Warmup Iteration  20: 26532.977 ns/op
Iteration   1: 25484.070 ns/op
Iteration   2: 19594.206 ns/op
Iteration   3: 30327.037 ns/op
Iteration   4: 31029.242 ns/op  <- xxx
Iteration   5: 19560.472 ns/op
Iteration   6: 19611.728 ns/op
Iteration   7: 23214.511 ns/op
Iteration   8: 28455.757 ns/op
Iteration   9: 19787.638 ns/op
Iteration  10: 23737.501 ns/op
Iteration  11: 25947.249 ns/op
Iteration  12: 19768.214 ns/op
Iteration  13: 25789.970 ns/op
Iteration  14: 20558.622 ns/op
Iteration  15: 19611.317 ns/op
Iteration  16: 27761.431 ns/op
Iteration  17: 19749.799 ns/op
Iteration  18: 20862.478 ns/op
Iteration  19: 19581.498 ns/op
Iteration  20: 28094.839 ns/op


latin1_Short_String, latin1_Short_char, latin1_mixed_String, 
latin1_mixed_char, utf16_mixed_String and utf16_mixed_char have all 
large error bars (all in StringIndexOfChar).



best regards,

michael



On 23.11.21 17:06, Michael Bien wrote:

On 23.11.21 15:57, Roger Riggs wrote:

Hi Michael,

As you might expect performance of strings is very sensitive and has 
been tuned extensively over the years many times.


Though this improves the performance for 1 character strings. It will 
have an impact on *every other* length of string.
You'll need to show that it does not impact performance of longer 
strings.


yes of course. The if (str.length == 1) branch should be dead code and 
eliminated by the JVM for all String constants with non-one lengths.


Looking through the benchmarks in micro/*/java/lang/String*, all seem 
to be using constants as parameter for indexOf(). To try to measure 
the impact of the if branch i would have to write a benchmark with a 
parameter which changes every iteration, right? Otherwise the branch 
will be optimized away by the JIT.




It may be worth looking further at other ways to achieve the result.


agreed, I tried the most obvious approach first, but there is a chance 
that the fast path can be put into the intrinsified 
StringLatin1/StringUTF16 code instead.


-michael




Regards, Roger


On 11/22/21 3:52 PM, Michael Bien wrote:

Hello,

I kept forgetting which variants of the String methods perform 
better with single-char-Strings and which with char (IDEs had the 
tendency to suggest the wrong variant since it changed between JDK 
releases). So i wrote JMH benchmarks and noticed that the last 
method with a performance difference seems to be String.indexOf() - 
all other variants performed equally (unless I overlooked some).


this might be fairly easy to fix:

https://github.com/openjdk/jdk/pull/6509

(side effect: contains("c") is also faster)

I haven't looked into the intrinsified code of StringLatin1 and 
StringUTF16 to check if it could be fixed there (mostly because i 
actually don't know how the JVM assembles those intrinsics). It 
might be possible to improve this for short Strings in general, not 
just for chars, dependent on why the intrinsified version is 
actually slower for single-char-Strings. I opted for the trivial fix 
in java code.


best regards,

michael

Re: RFR: 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs

[Stuart Monteith]

On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

@eastig could you review this please?

-

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

RFR: 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs

[Stuart Monteith]

Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
to finish before restarting trial method.

-

Commit messages:
 - 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs

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

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

Withdrawn: 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs

[Stuart Monteith]

On Thu, 25 Nov 2021 11:42:30 GMT, Stuart Monteith  wrote:

> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
> to finish before restarting trial method.

This pull request has been closed without being integrated.

-

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

RFR: 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs

[Stuart Monteith]

Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread 
to finish before restarting trial method.

-

Commit messages:
 - 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs

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

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Wed, 24 Nov 2021 19:40:38 GMT, Mark Reinhold  wrote:

> A user who’s not familiar with the lingo of [reproducible 
> builds](https://reproducible-builds.org/docs/source-date-epoch/) will be 
> mystified by an option named `--source-date`. A user who just wants to set 
> the timestamp of new entries won’t be looking for an option whose name 
> includes “source.”
> 
> Please consider providing a more general option, say `--date`, which takes an 
> [ISO 8601 date/time 
> string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).
>  That would solve the general problem while also satisfying the requirement 
> for reproducible builds. In the build it’s easy enough to convert the 
> seconds-since epoch value of `SOURCE_DATE_EPOCH` to an ISO 8601 string (`date 
> -d @$SOURCE_DATE_EPOCH --iso-8601=seconds`).

Thanks @mbreinhold , good point, i'll update to use --date=

-

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Wed, 24 Nov 2021 16:48:42 GMT, Lance Andersen  wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>
> src/jdk.jartool/share/man/jar.1 line 1:
> 
>> 1: .\" Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights 
>> reserved.
> 
> The man pages are maintained in the close repository

I'll raise a separate bug to get that changed

-

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Thu, 25 Nov 2021 09:37:59 GMT, Andrew Leonard  wrote:

>> test/jdk/tools/jar/JarEntryTime.java line 129:
>> 
>>> 127: // Make a jar file from that directory structure with
>>> 128: // --source-date set to epoch seconds 1647302400 (15/03/2022)
>>> 129: long sourceDate = 1647302400L;
>> 
>> Please consider  adding a few before Epoch test values.
>
> @LanceAndersen can you clarify your meaning here please? Are you referring to 
> negative sourceDate? I put in the CSR that it was seconds "since" epoch akin 
> to SOURCE_DATE_EPOCH, which as far as I can tell does not support negative 
> values, as some time implementations won't support that. 
> But this does imply I should add some -ve validation checks.

I think we could support -ve values, though i'd need to alter a couple of things

-

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

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen  wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonard 
>
> test/jdk/tools/jar/JarEntryTime.java line 129:
> 
>> 127: // Make a jar file from that directory structure with
>> 128: // --source-date set to epoch seconds 1647302400 (15/03/2022)
>> 129: long sourceDate = 1647302400L;
> 
> Please consider  adding a few before Epoch test values.

@LanceAndersen can you clarify your meaning here please? Are you referring to 
negative sourceDate? I put in the CSR that it was seconds "since" epoch akin to 
SOURCE_DATE_EPOCH, which as far as I can tell does not support negative values, 
as some time implementations won't support that. 
But this does imply I should add some -ve validation checks.

-

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

Re: Adding an @Immutable annotation to Java

[Andrew Haley]

On 11/25/21 08:27, Justin Dekeyser wrote:



Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?


And: does @Immutable mean deeply immutable? IMO it really should,
but that's harder to check, and we'd have to think about what this
means for binary compatibility.

On 11/25/21 08:39, Alberto Otero Rodríguez wrote:
> I have not thought about that. I'm not a Java expert.
>
> I just throwed the idea precisely to avoid "fake immutability", because a 
programmer could think one record is immutable simply by being a record, while this is false.
>
> There are probably lots of problems that need to be taken in consideration 
(like inheritance). But I just throw the idea because I think it would be a 
desirable feature.
>
> I would be grateful if some expert could deepen in possible problems and 
their solutions.

Everything is always harder than it looks at first.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: Adding an @Immutable annotation to Java

[Alberto Otero Rodríguez]

I have not thought about that. I'm not a Java expert.

I just throwed the idea precisely to avoid "fake immutability", because a 
programmer could think one record is immutable simply by being a record, while 
this is false.

There are probably lots of problems that need to be taken in consideration 
(like inheritance). But I just throw the idea because I think it would be a 
desirable feature.

I would be grateful if some expert could deepen in possible problems and their 
solutions.

Regards,

Alberto Otero Rodríguez.

De: Justin Dekeyser 
Enviado: jueves, 25 de noviembre de 2021 9:27
Para: Alberto Otero Rodríguez 
Cc: core-libs-dev@openjdk.java.net 
Asunto: Re: Adding an @Immutable annotation to Java

Hello,

Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?
if no: that's a bit annoying, no? (fake immutability)
Can @Immutable class be subclassed to a non @Immutable one? if no:
that's a bit annoying too, no? (downcasting)

Since Object is the super class of everything, it sounds like a
problem. What have you thought about to handle this concern?

Regards,

Justin Dekeyser

On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
 wrote:
>
> Hi, I was thinking that it could be interesting adding an @Immutable 
> annotation to Java. It would be a marker annotation for the compiler (similar 
> to @FunctionalInterface) in order to throw an error if the annotated 
> class/record has a component that is not @Immutable.
>
> This means that all existing immutable objects (like the primitive-wrapping 
> objects and String) should be annotated with @Immutable and the programmer 
> could, for example, annotate a new record object with @Immutable only if all 
> its fields are annotated with @Immutable.
>
> What do you think?
>
> Regards,
>
> Alberto Otero Rodríguez.

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard  wrote:

>> Add a new --source-date  (epoch seconds) option to jar and jmod 
>> to allow specification of time to use for created/updated jar/jmod entries. 
>> This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard 
>
> Andrew Leonard has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>
>Signed-off-by: Andrew Leonard 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>
>Signed-off-by: Andrew Leonard 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>
>Signed-off-by: Andrew Leonard 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>
>Signed-off-by: Andrew Leonard 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>
>Signed-off-by: Andrew Leonard 

> I just tested this pull request by building [my JavaFX pull 
> request](https://github.com/openjdk/jfx/pull/446) on six Linux architectures, 
> and it works beautifully!
> 
> First I built this pull request branch of OpenJDK for Linux on the following 
> hardware platforms: amd64 (x86_64), arm64 (aarch64), armhf (armv7l), i386 
> (i636), ppc64el (ppc64le), and s390x (s390x).
> 
> Then I added three lines of Groovy code to the JavaFX `build.gradle` file 
> where it invokes the `jmod` tool:
> 
> ```groovy-gradle
> if (sourceDateEpoch != null) {
> args("--source-date", sourceDateEpoch)
> }
> ```
> 
> Then I built JavaFX twice for each of the architectures, with each build on a 
> clean, isolated container created from scratch. The result is 6 architectures 
> × 4,360 files = 26,160 identical files between the two sets of builds. The 
> JMOD archives were the last missing piece for JavaFX, so thank you, Andrew, 
> for completing the puzzle.
> 
> By the way, my builds of OpenJDK did not include your `jarjmodorder` branch, 
> yet the order for the entries in the JMOD archives are the same. In fact, I 
> checked my old builds and the entry order has always been the same between 
> builds for the JMOD archives. Only the entry timestamps were different. Is 
> that expected? I mean, although the order is not deterministic, is it 
> expected that they would end up in the same order when the archives are built 
> in the same environment by the same build process?

@jgneff thank you for testing, that's great news
on the "ordering" issue, it depends on your OS architecture among probably 
other things... for example try this:
- Build 1: on a Ubuntu 20.04 running on an Intel processor
- Build 2: on a Ubuntu 20.04 running on an AMD processor
I suspect you will find the order will differ...

-

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

Re: RFR: 8177819: DateTimeFormatterBuilder zone parsing should recognise DST [v3]

[Stephen Colebourne]

On Wed, 24 Nov 2021 23:25:22 GMT, Naoto Sato  wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for 
>> selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Replaced integer literals.
>  - Refined wording #2

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 508:

> 506:  * of {@link ChronoLocalDateTime#atZone(ZoneId)}. If the {@code ZoneId} 
> was
> 507:  * parsed from the zone name that does not indicate daylight saving 
> time, then
> 508:  * the standard offset will be used at the local time-line overlap.

As written, I would read it as being the generic zone name that gets altered, 
rather than a zone name that explicitly indicates "winter" time. maybe:

"If the {@code ZoneId} was parsed from a zone name that indicates whether 
daylight saving time in in operation or not, then that fact will be used to 
select the correct offset at the local time-line overlap."

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 
4906:

> 4904: private static class LENIENT extends CI {
> 4905: 
> 4906: private LENIENT(String k, String v, int t, PrefixTree 
> child) {

Is class `LENIENT` actually in use?

-

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

Re: Adding an @Immutable annotation to Java

[Justin Dekeyser]

Hello,

Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?
if no: that's a bit annoying, no? (fake immutability)
Can @Immutable class be subclassed to a non @Immutable one? if no:
that's a bit annoying too, no? (downcasting)

Since Object is the super class of everything, it sounds like a
problem. What have you thought about to handle this concern?

Regards,

Justin Dekeyser

On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
 wrote:
>
> Hi, I was thinking that it could be interesting adding an @Immutable 
> annotation to Java. It would be a marker annotation for the compiler (similar 
> to @FunctionalInterface) in order to throw an error if the annotated 
> class/record has a component that is not @Immutable.
>
> This means that all existing immutable objects (like the primitive-wrapping 
> objects and String) should be annotated with @Immutable and the programmer 
> could, for example, annotate a new record object with @Immutable only if all 
> its fields are annotated with @Immutable.
>
> What do you think?
>
> Regards,
>
> Alberto Otero Rodríguez.

Adding an @Immutable annotation to Java

[Alberto Otero Rodríguez]

Hi, I was thinking that it could be interesting adding an @Immutable annotation 
to Java. It would be a marker annotation for the compiler (similar to 
@FunctionalInterface) in order to throw an error if the annotated class/record 
has a component that is not @Immutable.

This means that all existing immutable objects (like the primitive-wrapping 
objects and String) should be annotated with @Immutable and the programmer 
could, for example, annotate a new record object with @Immutable only if all 
its fields are annotated with @Immutable.

What do you think?

Regards,

Alberto Otero Rodríguez.