> The current pure Java implementation does two things: it provides a fallback
> for pure-interpreter JVMs and it provides the reader with a simple
> implementation.
> I'm not at all sure we'd want a complex implementation.
I thought this might be the case.
> Having said that, if I were looking
I know java.lang.StringCoding.hasNegatives has a
HotSpotIntrinsicCandidate annotation/implementation, but is there
interest/value in a faster pure java implementation?
Using Unsafe to read and compare 8 bytes at a time as a long is faster
than the current simple implementation both in interpreter
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Sat, 9 Jan 2021 23:06:22 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#r
On Wed, 6 Jan 2021 15:36:21 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Wed, 25 Nov 2020 14:07:04 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by @Pau
On Mon, 4 Jan 2021 19:52:18 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
What guarantees that if the first read does not see null, the second read
will not see null?
Sections 4.2 and 4.4 of Aleksey’s “Close Encounters of the JMM Kind” seem
to show that such scenario is possible in face of concurrent setting of
non-volatile variable.
https://shipilev.net/blog/2016/close
I am cross posting this from the nio-dev mailing list.
The javadoc for SoftReference states:
All soft references to softly-reachable objects are guaranteed to have
been cleared before the virtual machine throws an OutOfMemoryError.
As pointed out in the nio-dev thread, there are some exceptions t
10 matches
Mail list logo
