On Thu, 15 Oct 2020 19:20:28 GMT, Ian Graves wrote:
>> The `java.util.Formatter` format specifies support for field widths,
>> argument indexes, or precision lengths of a field that relate to the
>> variadic arguments supplied to the formatter. These numbers are specified by
>> integers,
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>
On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung wrote:
>> I just want to note that if you have a `Reference ref` at hand,
>> you can not just do:
>> Referemce r = (Reference) ref;
>> ...since those generic types are not related. You have to do something like:
>>
>>
A method's or constructor's owner type might carry annotations on its potential
type parameters but is never represented as parameterized type what makes these
parameters inaccessible at runtime, despite the presence of parameter type
annotations.
-
Commit messages:
- 8202471: A
On Thu, 22 Oct 2020 20:40:00 GMT, CoreyAshford
wrote:
>> Thanks for this question. I also stumbled over it when reviewing. I guess a
>> branch which gets mispredicted in ~22% of the cases leads to a big
>> performance loss. (In addition, the branch target is not aligned.)
>
> Yes, it assumes
On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung wrote:
>> I just want to note that if you have a `Reference ref` at hand,
>> you can not just do:
>> Referemce r = (Reference) ref;
>> ...since those generic types are not related. You have to do something like:
>>
>>
> Hi,
>
> This patch adds an asExact() combinator to VarHandle, that will return a new
> VarHandle that performs exact type checks, similar to
> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
> which can lead to performance degradation.
>
> This is implemented
