Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

[Bernd Eckenfels]

Hello, sorry for being unpopular, but I just hate it to waste developer 
resources,

I realy think this deprecation message should be re-considered, it broke a lot 
of things, the amount of work to implement a caching solution feels like a 
waste of time and on top of it, there is no clear replacement strategy 
published yet.

I would restrict deprication (for removal if you really insist) to javadoc and 
not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no 
need to further damage java reputation by breaking perfectly working inter 
process interfaces. (This is btw true for all such warnings). And I also think 
top priority should be to publish a go-forward route which should not depend 
solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von Daniel 
Fuchs 
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-dev@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager 
should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` 
> and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335: = Collections.synchronizedMap(new WeakHashMap<>());
> 336: }
> 337:

I wonder about the use of a WeakHashMap here. That may work well when the 
source is an interned string (a class name) which will be strongly referenced 
elsewhere and may be garbage collected if the class is unloaded, but in the 
case where it contains the name of the source jar then that string will only be 
referenced by the weak hashmap, and therefore it could be garbage collected any 
time - which would cause the mapping to be removed. In that case you cannot 
guarantee that the warning will be emitted only once.

-

PR: https://git.openjdk.java.net/jdk17/pull/166

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

[Alan Bateman]

On 30/06/2021 08:19, Bernd Eckenfels wrote:
Hello, sorry for being unpopular, but I just hate it to waste 
developer resources,


I realy think this deprecation message should be re-considered, it 
broke a lot of things, the amount of work to implement a caching 
solution feels like a waste of time and on top of it, there is no 
clear replacement strategy published yet.


I would restrict deprication (for removal if you really insist) to 
javadoc and not poison stdout/stderr.




The purpose of the warning message is to make it very clear that 
applications that call System.setSecurityManager in a running VM will 
fail in the future. It is not hugely different to the "Illegal 
reflective access" warning that were emitted in JDK 9 to JDK 15. Maybe 
you could clarify what you mean by "it broke a lot of things". If you 
have something that is sensitive to warnings going to stderr then I 
would have expected the "Illegal reflective access" warnings to have 
caused a lot more issues.


-Alan.

Re: [jdk17] RFR: 8269486: CallerAccessTest fails for non server variant [v2]

[Christoph Göttschkes]

On Mon, 28 Jun 2021 14:52:41 GMT, Christoph Göttschkes  wrote:

>> Hi,
>> 
>> please review this small fix. The test case uses a custom launcher and 
>> before launching the JVM, it adds the "lib" and "lib/server" directories to 
>> the environment variable which controls the native library search path. For 
>> non server variants, the second directory is not called "lib/server", but 
>> "lib/client", for instance.
>> 
>> I changed the test case to use the utility methods in `Platform` to get the 
>> correct paths, dependent on the VM variant.
>
> Christoph Göttschkes has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Renames serverDir to vmDir.

Thanks for the reviews and testing.

-

PR: https://git.openjdk.java.net/jdk17/pull/159

RFR: 8269665: Clean-up toString() methods of some primitive wrappers

[Сергей Цыпанов]

As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and 
`Float` in their implementations of `Object.toString()` delegate to own utility 
`toString(primitive)` methods.

Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the 
contents of utility methods in implementations of `Object.toString()`.

Yet another issue is a tiny discrepancy in implementation related to `Byte` and 
`Short` (see the first):

public static String toString(byte b) {
return Integer.toString((int)b, 10);
}

public String toString() {
return Integer.toString((int)value);
}

Unlike in overriden method, In utility one they explicitly specify radix which 
can be skipped, as implementation of `Integer.toString(int,int)` has a 
fast-path for radix 10, ending in `Integer.toString(int)`. This simplification 
gives tiny improvement, see benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class ByteToStringBenchmark {
@Benchmark
public String byteToString() {
return Byte.toString((byte) 1);
}
}

Results:

before

BenchmarkMode  Cnt  
   Score Error   Units
ByteToStringBenchmark.byteToString   avgt   30  
  11,648 ±   1,906   ns/op
ByteToStringBenchmark.byteToString:·gc.alloc.rateavgt   30  
3288,576 ± 418,119  MB/sec
ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm   avgt   30  
  48,001 ±   0,001B/op
ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space   avgt   30  
3301,804 ± 455,932  MB/sec
ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm  avgt   30  
  48,158 ±   2,085B/op
ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space   avgt   30  
   0,004 ±   0,001  MB/sec
ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm  avgt   30  
  ≈ 10⁻⁴  B/op
ByteToStringBenchmark.byteToString:·gc.count avgt   30  
 202,000counts
ByteToStringBenchmark.byteToString:·gc.time  avgt   30  
 413,000ms

after

BenchmarkMode  Cnt  
   Score Error   Units
ByteToStringBenchmark.byteToString   avgt   30  
  10,016 ±   0,530   ns/op
ByteToStringBenchmark.byteToString:·gc.alloc.rateavgt   30  
3673,700 ± 167,450  MB/sec
ByteToStringBenchmark.byteToString:·gc.alloc.rate.norm   avgt   30  
  48,001 ±   0,001B/op
ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space   avgt   30  
3662,406 ± 205,978  MB/sec
ByteToStringBenchmark.byteToString:·gc.churn.G1_Eden_Space.norm  avgt   30  
  47,870 ±   1,750B/op
ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space   avgt   30  
   0,004 ±   0,002  MB/sec
ByteToStringBenchmark.byteToString:·gc.churn.G1_Survivor_Space.norm  avgt   30  
  ≈ 10⁻⁴  B/op
ByteToStringBenchmark.byteToString:·gc.count avgt   30  
 224,000counts
ByteToStringBenchmark.byteToString:·gc.time  avgt   30  
 358,000ms

-

Commit messages:
 - 8269665: Clean-up toString() methods of some primitive wrappers

Changes: https://git.openjdk.java.net/jdk/pull/4633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269665
  Stats: 10 lines in 4 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633

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

Re: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v6]

[Jan Lahoda]

> Currently, an enum switch with patterns is desugared in a very non-standard, 
> and potentially slow, way. It would be better to use the standard 
> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to 
> accept enum constants as labels in order to allow this. A complication is 
> that if an enum constant is missing, that is not an incompatible change for 
> the switch, and the switch should simply work as if the case for the missing 
> constant didn't exist. So, the proposed solution is to have a new bootstrap 
> `enumSwitch` that accepts `String`s in place of the enum constants, and will 
> internally convert them to the appropriate enum constants, and then it will 
> find the proper case similarly to `typeSwitch`.
> 
> How does this look?

Jan Lahoda has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains ten commits:

 - Reflecting review comments.
 - Merge branch 'master' into JDK-8268766
 - Improving javadoc.
 - Updating javadoc, as suggested.
 - Updating javadoc, code and tests as suggested.
 - Creating a new bootstrap method for (pattern matching) enum switches, as 
suggested.
 - Adding and fixing test.
 - Merging master.
 - 8268766: Desugaring of pattern matching enum switch should be improved

-

Changes: https://git.openjdk.java.net/jdk17/pull/81/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=05
  Stats: 416 lines in 6 files changed: 278 ins; 68 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

Re: RFR: 8266054: VectorAPI rotate operation optimization [v9]

[Jatin Bhateja]

> Current VectorAPI Java side implementation expresses rotateLeft and 
> rotateRight operation using following operations:-
> 
> vec1 = lanewise(VectorOperators.LSHL, n)
> vec2 = lanewise(VectorOperators.LSHR, n)
> res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which 
> facilitates dismantling the rotate operation if target ISA does not support a 
> direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over 
> long and integer type vectors. For other cases (i.e. sub-word type vectors or 
> for targets which do not support direct rotate operations )   instruction 
> sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt  AVX3 
> (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
>   |   |   |   |   |   |   |   |  
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 
> | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 
> 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | 
> -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 
> | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | 
> -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 
> | .44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 
> | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 
> | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 
> | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 
> | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | 
> -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 
> | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 
> | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 
> | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 
> | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 
> 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 
> 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 
> 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 
> 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 
> 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 
> 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 
> | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 
> | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 
> 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 
> | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 
> 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 
> 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 
> | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 
> 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 
> 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 
> | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 
> 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 
> 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 
> | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 
> 427.39 |

Re: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v2]

[Сергей Цыпанов]

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
> return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information 
> upfront. For example, depending on how you are generating the IDs, the upper 
> bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it 
> would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

Сергей Цыпанов has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains two additional 
commits since the last revision:

 - Merge branch 'master' into 8268764
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/27233ae1..12a1d3ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00-01

  Stats: 44011 lines in 878 files changed: 23038 ins; 17963 del; 3010 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

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

Re: RFR: 8268113: Re-use Long.hashCode() where possible [v8]

[Сергей Цыпанов]

> There is a few JDK classes duplicating the contents of Long.hashCode() for 
> hash code calculation. They should explicitly delegate to Long.hashCode().

Сергей Цыпанов has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains eight additional 
commits since the last revision:

 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/f1c8cc7b..4ec7c829

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06-07

  Stats: 56052 lines in 1127 files changed: 32406 ins; 19375 del; 4271 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

Re: RFR: 8263561: Re-examine uses of LinkedList [v3]

[Сергей Цыпанов]

> After I've renamed remove branch GitHub for some reason has closed original 
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.

Сергей Цыпанов has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
   
   # Conflicts:
   #src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java
 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-

Changes: https://git.openjdk.java.net/jdk/pull/4304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=02
  Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304

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

Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v3]

[Сергей Цыпанов]

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found 
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like 
> `baseName.replace('.', '/') + '/' + name` are not compiled into 
> `invokedynamic`-based code, but into one using `StringBuilder`. This happens 
> due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
> if (isArray()) {
> return getComponentType().getSimpleName() + "[]";
> }
> //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
> //fore some reason compiler doesn't allow me to call 
> Class.descriptorString() directly
> descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
> return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
> return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>Mode  Cnt Score 
> Error   Units
> descriptorString   avgt   6091.480 ±   
> 1.839   ns/op
> descriptorString:·gc.alloc.rate.norm   avgt   60   404.008 ±   
> 4.033B/op
> descriptorString:·gc.churn.G1_Eden_Space   avgt   60  2791.866 ± 
> 181.589  MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm  avgt   60   401.702 ±  
> 26.047B/op
> descriptorString:·gc.churn.G1_Survivor_Space   avgt   60 0.003 ±   
> 0.001  MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm  avgt   60≈ 10⁻³
>   B/op
> descriptorString:·gc.count avgt   60   205.000
> counts
> descriptorString:·gc.time  avgt   60   216.000
> ms
> 
> patched
>Mode  Cnt Score 
> Error   Units
> descriptorString   avgt   6065.016 ±   
> 3.446   ns/op
> descriptorString:·gc.alloc.rateavgt   60  2844.240 ± 
> 115.719  MB/sec
> descriptorString:·gc.alloc.rate.norm   avgt   60   288.006 ±   
> 0.001B/op
> descriptorString:·gc.churn.G1_Eden_Space   avgt   60  2832.996 ± 
> 206.939  MB/sec
> descriptorString:·gc.churn.G1_Eden_Space.norm  avgt   60   286.955 ±  
> 17.853B/op
> descriptorString:·gc.churn.G1_Survivor_Space   avgt   60 0.003 ±   
> 0.001  MB/sec
> descriptorString:·gc.churn.G1_Survivor_Space.norm  avgt   60≈ 10⁻³
>   B/op
> descriptorString:·gc.count avgt   60   208.000
> counts
> descriptorString:·gc.time  avgt   60   228.000
> ms
> -
> typeName   avgt   6034.273 ±   
> 0.480   ns/op
> typeName:·gc.alloc.rateavgt   60  3265.356 ±  
> 45.113  MB/sec
> typeName:·gc.alloc.rate.norm   avgt   60   176.004 ±   
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space   avgt   60  3268.454 ± 
> 134.458  MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm  avgt   60   176.109 ±   
> 6.595B/op
> typeName:·gc.churn.G1_Survivor_Space   avgt   60 0.003 ±   
> 0.001  MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm  avgt   60≈ 10⁻⁴
>   B/op
> typeName:·gc.count avgt   60   240.000
> counts
> typeName:·gc.time  avgt   60   255.000
> ms
> 
> patched
> 
> typeName   avgt   6015.787 ±   
> 0.214   ns/op
> typeName:·gc.alloc.rateavgt   60  2577.554 ±  
> 32.339  MB/sec
> typeName:·gc.alloc.rate.norm   avgt   6064.001 ±   
> 0.001B/op
> typeName:·gc.churn.G1_Eden_Space   avgt   60  2574.039 ± 
> 147.774  MB/sec
> typeName:·gc.churn.G1_Eden_Space.norm  avgt   6063.895 ±   
> 3.511B/op
> typeName:·gc.churn.G1_Survivor_Space   avgt   60 0.003 ±   
> 0.001  MB/sec
> typeName:·gc.churn.G1_Survivor_Space.norm  avgt   60≈ 10⁻⁴
>   B/op
> typeName:·gc.count avgt   60   189.000
> counts
> typeName:·gc.time  avgt   60   199.000
> ms
> 
> I think this patch is likely to improve reflecti

Re: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v2]

[Kevin Walls]

On Wed, 30 Jun 2021 11:49:51 GMT, Сергей Цыпанов 
 wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>> return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information 
>> upfront. For example, depending on how you are generating the IDs, the upper 
>> bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it 
>> would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> Сергей Цыпанов has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains two additional 
> commits since the last revision:
> 
>  - Merge branch 'master' into 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

The changes look good to me, we have done the same thing elsewhere.  This 
changes things in different functional areas, which is maybe unusual, but seems 
fine for a small change as long as nobody objects.

Some of the files also need a (C) year update.

-

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

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

[Weijun Wang]

> Add a cache to record which sources have called `System::setSecurityManager` 
> and only print out warning lines once for each.

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

  update cache key from String to Class

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/166/files
  - new: https://git.openjdk.java.net/jdk17/pull/166/files/a9188921..c158d4bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=00-01

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

PR: https://git.openjdk.java.net/jdk17/pull/166

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

[Weijun Wang]

On Wed, 30 Jun 2021 06:32:04 GMT, Alan Bateman  wrote:

>> I hope this is uncommon but if that class is loaded by a `ClassLoader` again 
>> and again then it will be different each time. I'll investigate more.
>
> WeakHashMap, Boolean>, where the key is the caller, should be okay 
> (assume synchronization of course). Even with applications that do call 
> setSecurityManager then the map is probably going to be one entry. I wouldn't 
> expect it is common to create custom class loaders that load code that sets a 
> security manager, meaning it is more likely that the container sets the SM 
> rather have each plugin/application/whatever try to set the system-wide SM.

Thanks. Switched to Class as cache key. New commit pushed.

-

PR: https://git.openjdk.java.net/jdk17/pull/166

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v3]

[Jaikiran Pai]

> Can I please get a review for this proposed fix for the issue reported in 
> https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create 
> a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been 
> included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the 
> `ByteArrayOutputStream` with an initial size potentially as large as the 
> `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default 
> value. However, I think that can be addressed separately while dealing with 
> https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with two additional 
commits since the last revision:

 - an initial proposed test for testing compressed size entry greater than 2gb
 - minor summary update on test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/127acbcc..f519aa47

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=01-02

  Stats: 113 lines in 2 files changed: 112 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

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

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v2]

[Jaikiran Pai]

Hello Lance,

On 29/06/21 11:31 pm, Lance Andersen wrote:


I ran your current test 150 times and the max runtime was 25 seconds, most 
cases were in the 18-20 second range on our slower test boxes.


Thank you for running those tests. Do you think those timings are good 
enough to let that test stay as a regular automated jtreg test, in 
tier1? I'm guessing this falls in tier1? I haven't yet looked in detail 
the tier definitions of the build.




As part of looking at what happens with a file whose deflated size is > 2gb, I 
would add a specific test which is a manual test to validate that there is no 
issue when we cross the 2gb threshold.


I added a (manual) test to see what happens in this case. I have 
committed the test as part of this PR just for the sake of reference. 
The test is named LargeCompressedEntrySizeTest. The test uses ZipFS to 
create a (new) zip file and attempts to write out a zip entry whose 
deflated/compressed size is potentially greater than 2gb. When I run 
this test case, I consistenly run into the following exception:


test LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(): 
failure
java.lang.OutOfMemoryError: Required array length 2147483639 + 419 is 
too large
    at 
java.base/jdk.internal.util.ArraysSupport.hugeLength(ArraysSupport.java:649)
    at 
java.base/jdk.internal.util.ArraysSupport.newLength(ArraysSupport.java:642)
    at 
java.base/java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
    at 
java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130)
    at 
java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
    at 
java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
    at 
jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$DeflatingEntryOutputStream.write(ZipFileSystem.java:2016)
    at 
java.base/java.io.FilterOutputStream.write(FilterOutputStream.java:108)
    at 
LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(LargeCompressedEntrySizeTest.java:104)


which to me is understandable. Is this what you and Alan wanted 
tested/checked? In its current form I don't see a way to write out a 
entry whose deflated size exceeds 2gb, unless the user/caller use the 
"useTempFile=true" option while creating the zip filesystem. FWIW - if I 
do set this "useTempFile=true" while creating that zip filesystem, in 
the LargeCompressedEntrySizeTest, that test passes fine and the 
underlying zip that is created shows a compressed/deflated size as follows:


unzip -lv JTwork/scratch/8190753-test-compressed-size.zip
Archive:  JTwork/scratch/8190753-test-compressed-size.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
  --  ---  -- -   
2147483649  Defl:N 2148138719   0% 06-30-2021 21:39 52cab9f8 
LargeZipEntry.txt

  ---  ---    ---
2147483649 2148138719   0%    1 file


I understand that Alan's suggestion holds good and we should have some 
logic in place which switches to using a temp file once we notice that 
the sizes we are dealing with can exceed some threshold, but I guess 
that is something we need to do separately outside of this PR?


-Jaikiran

Re: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v6]

[Paul Sandoz]

On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, 
>> and potentially slow, way. It would be better to use the standard 
>> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs 
>> to accept enum constants as labels in order to allow this. A complication is 
>> that if an enum constant is missing, that is not an incompatible change for 
>> the switch, and the switch should simply work as if the case for the missing 
>> constant didn't exist. So, the proposed solution is to have a new bootstrap 
>> `enumSwitch` that accepts `String`s in place of the enum constants, and will 
>> internally convert them to the appropriate enum constants, and then it will 
>> find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains ten commits:
> 
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8268766
>  - Improving javadoc.
>  - Updating javadoc, as suggested.
>  - Updating javadoc, code and tests as suggested.
>  - Creating a new bootstrap method for (pattern matching) enum switches, as 
> suggested.
>  - Adding and fixing test.
>  - Merging master.
>  - 8268766: Desugaring of pattern matching enum switch should be improved

Marked as reviewed by psandoz (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/81

Integrated: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML

[Masanori Yano]

On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano  wrote:

> Hi all,
> 
> Could you please review the 8268457 bug fixes?
> 
> The problem is that ToHTMLStream applies processing for non-surrogate pairs 
> to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else condition.

This pull request has now been integrated.

Changeset: 83bce94c
Author:Masanori Yano 
Committer: Joe Wang 
URL:   
https://git.openjdk.java.net/jdk/commit/83bce94cc8a7fb45b0604598411fbecc62000dfd
Stats: 194 lines in 7 files changed: 168 ins; 21 del; 5 mod

8268457: XML Transformer outputs Unicode supplementary character incorrectly to 
HTML

Reviewed-by: lancea, naoto, iris, joehw

-

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

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

[Jaikiran Pai]

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang  wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` 
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   update cache key from String to Class

FWIW - I built a local JDK with this PR and gave it a try against one of the 
original Apache Ant project example where the warnings were previously flooding 
the stderr. With this change, I now see the warning message just once (as 
expected) for that example.

-

PR: https://git.openjdk.java.net/jdk17/pull/166

[jdk17] RFR: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

[Mandy Chung]

`Reference::refersTo` behaves the same for soft, weak, and phantom references 
whereas `PhantomReference::get` always returns `null` which is different than 
soft and weak references. 

This patch clarifies the specification of `PhantomReference` to make it clear 
that `refersTo` can be used for phantom references.  With `refersTo`, phantom 
references if not registered in a reference queue are not completely useless.  
Update the javadoc of the constructor to reflect that.

I created a CSR to document this spec clarification:
   https://bugs.openjdk.java.net/browse/JDK-8269688

-

Commit messages:
 - JDK-8262841: Behavior of PhantomReference.refersTo is not well documented

Changes: https://git.openjdk.java.net/jdk17/pull/181/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=181&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262841
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/181.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/181/head:pull/181

PR: https://git.openjdk.java.net/jdk17/pull/181

Re: [jdk17] RFR: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

[Kim Barrett]

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references 
> whereas `PhantomReference::get` always returns `null` which is different than 
> soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear 
> that `refersTo` can be used for phantom references.  With `refersTo`, phantom 
> references if not registered in a reference queue are not completely useless. 
>  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>https://bugs.openjdk.java.net/browse/JDK-8269688

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/181

[jdk17] Integrated: 8269486: CallerAccessTest fails for non server variant

[Christoph Göttschkes]

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph Göttschkes  wrote:

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before 
> launching the JVM, it adds the "lib" and "lib/server" directories to the 
> environment variable which controls the native library search path. For non 
> server variants, the second directory is not called "lib/server", but 
> "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the 
> correct paths, dependent on the VM variant.

This pull request has now been integrated.

Changeset: 1da5d4bb
Author:Christoph Göttschkes 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk17/commit/1da5d4bb780fc3ab02aa6cddc243fbf1b079851a
Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod

8269486: CallerAccessTest fails for non server variant

Reviewed-by: dholmes, stuefe, mchung, jvernee

-

PR: https://git.openjdk.java.net/jdk17/pull/159

[jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

[Mandy Chung]

This spec clarification is a follow-up to 
[JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
 w.r.t. reference processing.  Since there is no guarantee for any memory 
reclamation by the invocation of `System::gc`, the spec should also clarify 
that there is no guarantee in determining the change of reachability of any 
objects or any particular number of `Reference` objects be enqueued and cleared.

CSR:
   https://bugs.openjdk.java.net/browse/JDK-8269690

-

Commit messages:
 - JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

Changes: https://git.openjdk.java.net/jdk17/pull/183/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225667
  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183

PR: https://git.openjdk.java.net/jdk17/pull/183

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

[Roger Riggs]

On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung  wrote:

> This spec clarification is a follow-up to 
> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>  w.r.t. reference processing.  Since there is no guarantee for any memory 
> reclamation by the invocation of `System::gc`, the spec should also clarify 
> that there is no guarantee in determining the change of reachability of any 
> objects or any particular number of `Reference` objects be enqueued and 
> cleared.
> 
> CSR:
>https://bugs.openjdk.java.net/browse/JDK-8269690

Marked as reviewed by rriggs (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/183

Re: [jdk17] RFR: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

[Roger Riggs]

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references 
> whereas `PhantomReference::get` always returns `null` which is different than 
> soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear 
> that `refersTo` can be used for phantom references.  With `refersTo`, phantom 
> references if not registered in a reference queue are not completely useless. 
>  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>https://bugs.openjdk.java.net/browse/JDK-8269688

Marked as reviewed by rriggs (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/181

RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError

[Sergei Ustimenko]

Change #3294 helps to avoid `AnnotaionFormatException` in 
`sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. 
While it fixes the case with e.g. `Runnable`  that generates the synthetic 
method without parameters, validation still fails on synthetic methods that 
have parameters e.g. `Function`, `BiFunction`, etc.

This change removes the restriction on parameters count to be zero i.e. lambdas 
with parameters
would be skipped from validation.

-

Commit messages:
 - 8268788: Annotations with lambda expressions can still cause 
AnnotationFormatError

Changes: https://git.openjdk.java.net/jdk/pull/4642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268788
  Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642

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

Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v2]

[Lance Andersen]

Hi Jaikiran

On Jun 30, 2021, at 12:15 PM, Jaikiran Pai 
mailto:jai.forums2...@gmail.com>> wrote:

Hello Lance,

On 29/06/21 11:31 pm, Lance Andersen wrote:

I ran your current test 150 times and the max runtime was 25 seconds, most 
cases were in the 18-20 second range on our slower test boxes.

Thank you for running those tests. Do you think those timings are good enough 
to let that test stay as a regular automated jtreg test, in tier1? I'm guessing 
this falls in tier1? I haven't yet looked in detail the tier definitions of the 
build.

These tests run as part of tier2.

The time for the test run is reasonable .


As part of looking at what happens with a file whose deflated size is > 2gb, I 
would add a specific test which is a manual test to validate that there is no 
issue when we cross the 2gb threshold.

I added a (manual) test to see what happens in this case. I have committed the 
test as part of this PR just for the sake of reference. The test is named 
LargeCompressedEntrySizeTest. The test uses ZipFS to create a (new) zip file 
and attempts to write out a zip entry whose deflated/compressed size is 
potentially greater than 2gb. When I run this test case, I consistenly run into 
the following exception:

test LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(): failure
java.lang.OutOfMemoryError: Required array length 2147483639 + 419 is too large
at 
java.base/jdk.internal.util.ArraysSupport.hugeLength(ArraysSupport.java:649)
at 
java.base/jdk.internal.util.ArraysSupport.newLength(ArraysSupport.java:642)
at 
java.base/java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
at 
java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130)
at 
java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
at 
java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
at 
jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$DeflatingEntryOutputStream.write(ZipFileSystem.java:2016)
at java.base/java.io.FilterOutputStream.write(FilterOutputStream.java:108)
at 
LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(LargeCompressedEntrySizeTest.java:104)

which to me is understandable. Is this what you and Alan wanted tested/checked? 
In its current form I don't see a way to write out a entry whose deflated size 
exceeds 2gb, unless the user/caller use the "useTempFile=true" option while 
creating the zip filesystem. FWIW - if I do set this "useTempFile=true" while 
creating that zip filesystem, in the LargeCompressedEntrySizeTest, that test 
passes fine and the underlying zip that is created shows a compressed/deflated 
size as follows:

unzip -lv JTwork/scratch/8190753-test-compressed-size.zip
Archive:  JTwork/scratch/8190753-test-compressed-size.zip
 Length   MethodSize  CmprDateTime   CRC-32   Name
  --  ---  -- -   
2147483649  Defl:N 2148138719   0% 06-30-2021 21:39 52cab9f8 LargeZipEntry.txt
  ---  ------
2147483649 2148138719   0%1 file


I understand that Alan's suggestion holds good and we should have some logic in 
place which switches to using a temp file once we notice that the sizes we are 
dealing with can exceed some threshold, but I guess that is something we need 
to do separately outside of this PR?

Yes the intent would be to add some logic, which might need to be under a 
property (for now) to specify the size for when to use  a temp file vs BAOS.  
Having the value configurable via a property might give us some flexibility for 
experimentation.

I don’t see why this PR could not be used for this (as it would provide a more 
complete solution)

Best
Lance

-Jaikiran



[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: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

[Kim Barrett]

On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung  wrote:

> This spec clarification is a follow-up to 
> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>  w.r.t. reference processing.  Since there is no guarantee for any memory 
> reclamation by the invocation of `System::gc`, the spec should also clarify 
> that there is no guarantee in determining the change of reachability of any 
> objects or any particular number of `Reference` objects be enqueued and 
> cleared.
> 
> CSR:
>https://bugs.openjdk.java.net/browse/JDK-8269690

Changes requested by kbarrett (Reviewer).

src/java.base/share/classes/java/lang/Runtime.java line 661:

> 659:  * the change of reachability in any particular number of objects
> 660:  * or any particular number of {@link java.lang.ref.Reference 
> Reference}
> 661:  * objects be cleared and enqueued.

perhaps
s/number of objects or any/number of objects, or that any/
s/objects be/objects will be/

src/java.base/share/classes/java/lang/System.java line 1867:

> 1865:  * the change of reachability in any particular number of objects
> 1866:  * or any particular number of {@link java.lang.ref.Reference 
> Reference}
> 1867:  * objects be cleared and enqueued.

Similar suggestion here as for Runtime.gc.

-

PR: https://git.openjdk.java.net/jdk17/pull/183

[jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()

[Naoto Sato]

A trivial typo fix.

-

Commit messages:
 - 8269704: Typo in j.t.Normalizer.normalize()

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

PR: https://git.openjdk.java.net/jdk17/pull/187

[jdk17] Integrated: 8269513: Clarify the spec wrt `useOldISOCodes` system property

[Naoto Sato]

On Mon, 28 Jun 2021 16:57:15 GMT, Naoto Sato  wrote:

> Please review this small doc change to the system property. Accompanying CSR 
> has also been created.

This pull request has now been integrated.

Changeset: 3e022247
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk17/commit/3e022247d2e80c43393bfdb5888b03210c6975d3
Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8269513: Clarify the spec wrt `useOldISOCodes` system property

Reviewed-by: lancea, bpb, iris, joehw

-

PR: https://git.openjdk.java.net/jdk17/pull/163

Re: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()

[Joe Wang]

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by joehw (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/187

Re: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()

[Pavel Rappo]

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by prappo (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/187

[jdk17] Integrated: JDK-8262841: Clarify the behavior of PhantomReference::refersTo

[Mandy Chung]

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references 
> whereas `PhantomReference::get` always returns `null` which is different than 
> soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear 
> that `refersTo` can be used for phantom references.  With `refersTo`, phantom 
> references if not registered in a reference queue are not completely useless. 
>  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>https://bugs.openjdk.java.net/browse/JDK-8269688

This pull request has now been integrated.

Changeset: 9ac63a6e
Author:Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk17/commit/9ac63a6e08c18ed99b97fe0abcc0ac51b96a563e
Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8262841: Clarify the behavior of PhantomReference::refersTo

Reviewed-by: kbarrett, rriggs

-

PR: https://git.openjdk.java.net/jdk17/pull/181

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

[Mandy Chung]

On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.java line 661:
> 
>> 659:  * the change of reachability in any particular number of objects
>> 660:  * or any particular number of {@link java.lang.ref.Reference 
>> Reference}
>> 661:  * objects be cleared and enqueued.
> 
> perhaps
> s/number of objects or any/number of objects, or that any/
> s/objects be/objects will be/

That may be clearer.  Updated.

-

PR: https://git.openjdk.java.net/jdk17/pull/183

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

[Mandy Chung]

> This spec clarification is a follow-up to 
> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>  w.r.t. reference processing.  Since there is no guarantee for any memory 
> reclamation by the invocation of `System::gc`, the spec should also clarify 
> that there is no guarantee in determining the change of reachability of any 
> objects or any particular number of `Reference` objects be enqueued and 
> cleared.
> 
> CSR:
>https://bugs.openjdk.java.net/browse/JDK-8269690

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

  Kim's suggestion on the wording

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/183/files
  - new: https://git.openjdk.java.net/jdk17/pull/183/files/e9765984..020a2d7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183

PR: https://git.openjdk.java.net/jdk17/pull/183

Re: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()

[Iris Clark]

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by iris (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/187

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v5]

[Brian Burkhalter]

On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and 
>> `read(byte[],int,int)` to return zero per the `InputStream` specification 
>> when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - 6766844: Move API note of read(byte[],int,int) to normative text
>  - 6766844: Change "equivalent" to "overridden"

This PR has been superseded by the JDK 17 PR 
[189](https://github.com/openjdk/jdk17/pull/189).

-

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

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

[Brian Burkhalter]

On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter  wrote:

> Modify the specification of 
> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is 
> returned instead of `0` when the stream is at its end and the third 
> parameter, `len`, is zero.

This PR supersedes PR [4591](https://github.com/openjdk/jdk/pull/4591).

-

PR: https://git.openjdk.java.net/jdk17/pull/189

[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

[Brian Burkhalter]

Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` 
to indicate that `-1` is returned instead of `0` when the stream is at its end 
and the third parameter, `len`, is zero.

-

Commit messages:
 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not 
consistent with InputStream when at EOF

Changes: https://git.openjdk.java.net/jdk17/pull/189/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6766844
  Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/189.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/189/head:pull/189

PR: https://git.openjdk.java.net/jdk17/pull/189

Withdrawn: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

[Brian Burkhalter]

On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter  wrote:

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and 
> `read(byte[],int,int)` to return zero per the `InputStream` specification 
> when the byte array actual or specified length is zero.

This pull request has been closed without being integrated.

-

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

RFR: 8188044: We need Math.unsignedMultiplyHigh

[Brian Burkhalter]

Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` 
to each of `java.lang.Math` and `java.lang.StrictMath`.

-

Commit messages:
 - 8188044: We need Math.unsignedMultiplyHigh

Changes: https://git.openjdk.java.net/jdk/pull/4644/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4644&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188044
  Stats: 72 lines in 3 files changed: 62 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4644/head:pull/4644

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

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh

[Brian Burkhalter]

On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter  wrote:

> Please consider this proposal to add a method 
> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and 
> `java.lang.StrictMath`.

This PR does not address intrinsics for the proposed method; that aspect can be 
handled subsequently.

-

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

RFR: Merge jdk17

[Jesper Wilhelmsson]

Forwardport JDK 17 -> JDK 18

-

Commit messages:
 - Merge
 - 8262841: Clarify the behavior of PhantomReference::refersTo
 - 8269703: ProblemList 
vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on 
Windows-X64 with -Xcomp
 - 8269513: Clarify the spec wrt `useOldISOCodes` system property
 - 8268897: [TESTBUG] compiler/compilercontrol/mixed/RandomCommandsTest.java 
must not fail on Command.quiet
 - 8268557: Module page uses unstyled table class
 - 8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
 - 8269486: CallerAccessTest fails for non server variant
 - 8269614: [s390] Interpreter checks wrong bit for slow path instance 
allocation
 - 8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating 
handle outside HandleMark
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/85262c71...d9b654b1

The webrevs contain the adjustments done while merging with regards to each 
parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4645/files
  Stats: 394 lines in 29 files changed: 280 ins; 26 del; 88 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645

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

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

[Kim Barrett]

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung  wrote:

>> This spec clarification is a follow-up to 
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>>  w.r.t. reference processing.  Since there is no guarantee for any memory 
>> reclamation by the invocation of `System::gc`, the spec should also clarify 
>> that there is no guarantee in determining the change of reachability of any 
>> objects or any particular number of `Reference` objects be enqueued and 
>> cleared.
>> 
>> CSR:
>>https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Kim's suggestion on the wording

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/183

Integrated: Merge jdk17

[Jesper Wilhelmsson]

On Thu, 1 Jul 2021 00:08:51 GMT, Jesper Wilhelmsson  
wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 9def3b06
Author:Jesper Wilhelmsson 
URL:   
https://git.openjdk.java.net/jdk/commit/9def3b068e9ee065e2e545bb35f8dc56ccfe5955
Stats: 394 lines in 29 files changed: 280 ins; 26 del; 88 mod

Merge

-

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

Re: RFR: Merge jdk17 [v2]

[Jesper Wilhelmsson]

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 125 commits:

 - Merge
 - 8268637: Update --release 17 symbol information for JDK 17 build 28
   
   Reviewed-by: iris
 - 8269678: Remove unimplemented and unused os::bind_to_processor()
   
   Reviewed-by: dcubed
 - 8268457: XML Transformer outputs Unicode supplementary character incorrectly 
to HTML
   
   Reviewed-by: lancea, naoto, iris, joehw
 - 8269516: AArch64: Assembler cleanups
   
   Reviewed-by: ngasson, adinn
 - 8261495: Shenandoah: reconsider update references memory ordering
   
   Reviewed-by: zgu, rkennke
 - 8269478: Shenandoah: gc/shenandoah/mxbeans tests should be more resilient
   
   Reviewed-by: rkennke
 - 8269416: [JVMCI] capture libjvmci crash data to a file
   
   Reviewed-by: kvn, dholmes
 - 8268906: gc/g1/mixedgc/TestOldGenCollectionUsage.java assumes that GCs take 
1ms minimum
   
   Reviewed-by: kbarrett, ayang, lkorinth
 - 8263461: jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java uses wrong 
mechanism to cause evacuation failure
   
   Reviewed-by: kbarrett, iwalulya, ayang
 - ... and 115 more: 
https://git.openjdk.java.net/jdk/compare/9ac63a6e...d9b654b1

-

Changes: https://git.openjdk.java.net/jdk/pull/4645/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=01
  Stats: 31079 lines in 656 files changed: 18219 ins; 10796 del; 2064 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645

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