Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-08 Thread duke
On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-03 Thread Bradford Wetmore
On Mon, 30 Jun 2025 15:20:33 GMT, Sean Mullan wrote: >> This won't appear in the list of methods declared by `SecureRandom`. An >> analogy is >> [`ConcurrentHashMap::forEach(BiConsumer)`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#me

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-03 Thread Bradford Wetmore
On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-02 Thread Koushik Muthukrishnan Thirupattur
On Thu, 3 Jul 2025 05:19:42 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The suggestion in the issue was to switch to RandomGenerator.nextLong() can >> you provide an explanation as to why that is not an acceptable solution. It >> would avoid any allocation. Thanks > >> The suggestion in

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-02 Thread Koushik Muthukrishnan Thirupattur
On Tue, 1 Jul 2025 02:02:33 GMT, Roger Riggs wrote: > The suggestion in the issue was to switch to RandomGenerator.nextLong() can > you provide an explanation as to why that is not an acceptable solution. It > would avoid any allocation. Thanks As per our offline discussion, I am keeping this

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-02 Thread Roger Riggs
On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-07-02 Thread Rajan Halade
On Mon, 30 Jun 2025 17:45:23 GMT, Koushik Muthukrishnan Thirupattur wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or

Re: RFR: 8357915: SecureRandom nextLong memory usage [v2]

2025-06-30 Thread Koushik Muthukrishnan Thirupattur
> SecureRandom uses straightforward implementations inherited from Random but > in the process does double the memory allocations necessary. > The delegation to SecureRandom.engineNextBytes does not provide `int` or > `long` values, the caller must allocate a byte array and assemble the value >

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-30 Thread Sean Mullan
On Mon, 30 Jun 2025 15:12:00 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/security/SecureRandom.java line 841: >> >>> 839: } >>> 840: >>> 841: @Override >> >> This method will appear in the javadoc for `SecureRandom` now, so I think >> you need to add the `inheritDoc` ta

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-30 Thread Chen Liang
On Mon, 30 Jun 2025 13:18:58 GMT, Sean Mullan wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or >> `long` values, the c

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-30 Thread Sean Mullan
On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur wrote: > SecureRandom uses straightforward implementations inherited from Random but > in the process does double the memory allocations necessary. > The delegation to SecureRandom.engineNextBytes does not provide `int` or > `

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-30 Thread Sean Mullan
On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur wrote: > SecureRandom uses straightforward implementations inherited from Random but > in the process does double the memory allocations necessary. > The delegation to SecureRandom.engineNextBytes does not provide `int` or > `

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-29 Thread Koushik Muthukrishnan Thirupattur
On Thu, 26 Jun 2025 18:16:28 GMT, Chen Liang wrote: >> SecureRandom uses straightforward implementations inherited from Random but >> in the process does double the memory allocations necessary. >> The delegation to SecureRandom.engineNextBytes does not provide `int` or >> `long` values, the ca

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-29 Thread Chen Liang
On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur wrote: > SecureRandom uses straightforward implementations inherited from Random but > in the process does double the memory allocations necessary. > The delegation to SecureRandom.engineNextBytes does not provide `int` or > `

Re: RFR: 8357915: SecureRandom nextLong memory usage

2025-06-29 Thread ExE Boss
On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur wrote: > SecureRandom uses straightforward implementations inherited from Random but > in the process does double the memory allocations necessary. > The delegation to SecureRandom.engineNextBytes does not provide `int` or > `

RFR: 8357915: SecureRandom nextLong memory usage

2025-06-29 Thread Koushik Muthukrishnan Thirupattur
SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary. The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself. So