On Mon, 31 May 2021 22:36:52 GMT, David Holmes wrote:
> > OTOH when CLASS retention is changing to RUNTIME, such as in this case, the
> > ways of looking up are widening (there is some new desire to lookup the
> > annotation at runtime via reflection). To facilitate that, the annotation
> >
On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote:
> That reads backwards to me. +PreserveAllAnnotations means that CLASS
> retention annotations are retained by the VM not just RUNTIME ones. So
> in that sense it might be a migration aid if moving from RUNTIME to
> CLASS, not CLASS to
On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote:
> > Hi Jaroslav,
> > If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to
> > re-compile any code that uses this annotation. You just have to use
> > `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and
>
On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach
wrote:
>> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
>> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>>
>> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code
>> that needs
On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach
wrote:
>> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
>> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>>
>> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code
>> that needs
On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach
wrote:
> My use-case relates to
> [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html)
> annotation used for Java/JavaScript interop. Originally all existing usages
> (Post Processing Classes,
On Thu, 27 May 2021 14:28:09 GMT, Aleksei Voitylov
wrote:
>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line
>> 481:
>>
>>> 479: throw new Error("Maximum lock count exceeded");
>>> 480: }
>>> 481:
>>
>> Hi Aleksei,
>> I know in practice this
On Thu, 27 May 2021 14:31:59 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>>
On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>>
On Wed, 26 May 2021 06:21:12 GMT, Peter Levart wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Editorial updates
>> Updated java.security properties to include jdk.serialFilte
On Tue, 25 May 2021 21:45:33 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On 21/05/2021 10:29, Peter Levart wrote:
I still haven't found a scenario of a possible deadlock when Sergei's
initial patch is combined with...
Sorry Aleksei, I renamed you to Sergei without intention. Please excuse me.
Peter
On 21/05/2021 01:11, David Holmes wrote:
Hi Peter,
On 21/05/2021 12:42 am, Peter Levart wrote:
Hi Aleksei,
Are you trying to solve this in principle or do you have a concrete
problem at hand which triggers this deadlock? If it is the later,
then some rearrangement of code might do
Hi Aleksei,
Are you trying to solve this in principle or do you have a concrete
problem at hand which triggers this deadlock? If it is the later, then
some rearrangement of code might do the trick... For example, native
libraries are typically loaded by a class initializer of some class that
On 20/05/2021 08:35, dfranken@gmail.com wrote:
I also think the proposal of Stuart is reasonable though, but it seemed
to me that we had reached some sort of impasse in this discussion. As
Remi points out, we have (default) methods which sometimes throw
exceptions when they are implemented
On 15/05/2021 19:50, Peter Levart wrote:
Another question: Suppose there are two inheritable ScopeLocal
variables with bound values in scope (A and B) when I take a snapshot:
var snapshot = ScopeLocal.snapshot();
now I pass that snapshot to a thread which does the following:
ScopeLocal
On Tue, 18 May 2021 23:14:53 GMT, Stephen Colebourne
wrote:
>> src/java.base/share/classes/java/time/Clock.java line 487:
>>
>>> 485: // it more unlikely to hit the 1ns in the future condition.
>>> 486: localOffset = System.currentTimeMillis()/1000 - 1024;
>>> 487:
>>
On Mon, 17 May 2021 17:19:19 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
Changes requested by plevart
Hi,
So if scopeLocal.get() is called in a thread outside any .run() scope in
that thread, it will throw exception and scopeLocal.isBound() will
return false. Unless it was called on an inheritableScopeLocal which
inherited binding from parent thread.
What if I wanted to create and start a
On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov
wrote:
> Please review this PR which fixes the deadlock in ClassLoader between the two
> lock objects - a lock object associated with the class being loaded, and the
> ClassLoader.loadedLibraryNames hash map, locked during the native library
On 5/12/21 2:55 AM, Stuart Marks wrote:
As you point out, add() is kind of like addLast(), except without the
reordering semantics for LinkedHashSet. And reversed().add() is a
roundabout way of saying addFirst() -- also without the reordering
semantics for LinkedHashSet. I think most
Hi Remi,
I see you avoided addFirst/addLast methods. While getFirst/removeFirst
could be specified to be consistent with iterator().next(), so the
"first" part of the name would be softer, addFirst is cursed two times:
it has no equivalent in current API and it clashes with void returning
On Thu, 6 May 2021 16:34:04 GMT, Peter Levart wrote:
>> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and
>> https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class`
>> expressions like
>>
>> String str = baseName.
On Thu, 6 May 2021 15:20:23 GMT, Сергей Цыпанов
wrote:
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 and
> https://github.com/openjdk/jdk/pull/2212 it appears, that in `j.l.Class`
> expressions like
>
> String str = baseName.replace('.', '/') + '/' + name;
>
> are not
On 4/30/21 9:25 PM, Stuart Marks wrote:
So I think we're stuck with void-returning add{First,Last} methods.
Have you thought of perhaps not adding them at all?
Collection.add() for:
List(s) - behaves the same as addLast()
LinkedHashSet - behaves the same as addLast()
Deque - behaves
On 4/28/21 7:19 AM, Stuart Marks wrote:
On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
wrote:
Now just some of my thoughts about the proposal:
- SortedSet.addFirst/.addLast - I think an operation that would be used
in situations like
On 4/28/21 2:04 AM, Stuart Marks wrote:
Binary compatibility is important. And I guess there is a variant of
the proposal that includes ReversibleCollection and ReversibleSet and
is binary compatible.
Yes, the source incompatibilities with the types seem to involve type
inference (e.g.,
On Tue, 27 Apr 2021 09:17:43 GMT, Сергей Цыпанов
wrote:
> > Also be careful not to return a string which
> > is not interned (which would happen if you did what you are proposing
> > above).
>
> Ok, I'm probably missing something, but when we move `String.intern()` call
> to `this.packageName
On 4/27/21 5:50 AM, Stuart Marks wrote:
On 4/25/21 11:09 AM, Peter Levart wrote:
When making this proposition, I was only thinking of how to enable
new yet-nonexistent operations on collections that have order / are
reversible and that the code calling these methods would already
knows
On 4/26/21 1:27 PM, Сергей Цыпанов wrote:
On Mon, 26 Apr 2021 08:45:52 GMT, Alan Bateman wrote:
@AlanBateman if DL is not responding, will it be ok to just revert the changes
related to `java.util.concurrent`?
That should be fine, the null check in Objects.equals is benign with these
On 4/23/21 8:33 AM, Stuart Marks wrote:
This is what I intended anyway, ie that its OK for "first" to work on
an unordered collection, just that addFirst() has very weak semantics
wrt first-ness.
"Ensures that this collection contains the specified element(optional
operation). This has the
On 4/22/21 12:14 AM, Stephen Colebourne wrote:
public interface Collection {
default E getFirst() { return iterator().next(); }
Searching for ".iterator().next()" yields 74 matches in JDK sources...
Peter
On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote:
> While JDK-8148937 improved StringJoiner class by replacing internal use of
> getChars that copies out characters from String elements into a char[] array
> with StringBuilder which is somehow more optimal, the improvement was
&
gs), while creation of garbage has been further reduced to an almost
> garbage-free operation.
>
> So WDYT?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Fork JVM 3 times in JMH test to smooth out variance in a particular
On Mon, 19 Apr 2021 10:44:04 GMT, Claes Redestad wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix overflow checking logic, add test for it, avoid branch in loop, add
>> 1-cha
On Mon, 19 Apr 2021 09:34:56 GMT, Alan Bateman wrote:
> an application or library can use the attach mechanism (directly or via the
> attach API in a child VM) to load an agent and leak the Instrumentation
> object. This is the genie that somehow needs to be put back in its bottle.
> One
contains one new commit since the last revision:
>
> 8200559: Java agents doing instrumentation need a means to define auxiliary
> classes
> This won't work as agents are loaded by the system class loader, not the boot
> loader. Peter Levart ***@***.***> schrieb am Mo., 19. Ap
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter
wrote:
>> To allow agents the definition of auxiliary classes, an API is needed to
>> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or
>> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed
On Fri, 16 Apr 2021 23:02:33 GMT, Peter Levart wrote:
>> src/java.base/share/classes/java/lang/String.java line 3254:
>>
>>> 3252:
>>> 3253: byte[] value = StringConcatHelper.newArray(((long) icoder <<
>>> 32) | llen);
>>> 3254:
On Sun, 18 Apr 2021 19:55:20 GMT, Peter Levart wrote:
>> While JDK-8148937 improved StringJoiner class by replacing internal use of
>> getChars that copies out characters from String elements into a char[] array
>> with StringBuilder which is somehow more optima
gs), while creation of garbage has been further reduced to an almost
> garbage-free operation.
>
> So WDYT?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Fix overflow checking logic, add test for it, avoid branch in loop, add
On 4/18/21 9:51 AM, Peter Levart wrote:
public interface Collection {
default Collection reversed() { return this; }
default void addFirst(E e) { throw new
UnsupportedOperationException(); }
default void addLast(E e) { throw new
UnsupportedOperationException
On 4/18/21 9:51 AM, Peter Levart wrote:
public interface Collection {
default Collection reversed() { return this; }
default void addFirst(E e) { throw new
UnsupportedOperationException(); }
default void addLast(E e) { throw new
UnsupportedOperationException
A word for Remi's concern...
While it is good that List (and SortedSet and Deque) extend
ReversibleCollection in the proposal, it is a pity the same is not true
for Set and Queue. If Set and Queue could also be
ReversibleCollection(s), then we would not need ReversibleCollection at
all and
On Fri, 16 Apr 2021 19:05:25 GMT, Roger Riggs wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add String.join benchmark method to StringJoinerBenchmark and adjust some
>> parameters
On Wed, 14 Apr 2021 20:03:27 GMT, Claes Redestad wrote:
> There's a StringJoinerBenchmark micro added by JDK-8148937 which could
> perhaps be expanded with the scenarios you've experimented with here?
I modified that micro benchmark and added a method to also measure String.join
static method
gs), while creation of garbage has been further reduced to an almost
> garbage-free operation.
>
> So WDYT?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Add String.join benchmark method to StringJoinerBenchmark and adjust so
On Wed, 14 Apr 2021 19:54:26 GMT, Florent Guillaume
wrote:
>> While JDK-8148937 improved StringJoiner class by replacing internal use of
>> getChars that copies out characters from String elements into a char[] array
>> with StringBuilder which is somehow more optimal, the improvement was
>>
On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote:
> While JDK-8148937 improved StringJoiner class by replacing internal use of
> getChars that copies out characters from String elements into a char[] array
> with StringBuilder which is somehow more optimal, the improvement was
&
While JDK-8148937 improved StringJoiner class by replacing internal use of
getChars that copies out characters from String elements into a char[] array
with StringBuilder which is somehow more optimal, the improvement was marginal
in speed (0% ... 10%) and mainly for smaller strings, while GC
Hi, Sergey!
Have you measured the code change in the java.lang.Class itself or just
equivalent code in the JMH test as you show us?
The JMH test may show better results as it is compiled to bytecode that
uses special invokedynamic-based string concatenation with optimal MH
based
Hi Ralph,
Which version of JDK did you try running the code. I tried the following
benchmark:
@BenchmarkMode(Mode.AverageTime)
@Fork(value = 1)
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 10, time = 1)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public
On Thu, 18 Mar 2021 14:30:21 GMT, Thomas Stuefe wrote:
>> The test expects there to be zero output from the child (and it doesn't
>> matter what state the child is in).
>> Can the logging from the VM be disabled or re-directed?
>
>> The test expects there to be zero output from the child (and
On Wed, 17 Mar 2021 14:16:36 GMT, Roger Riggs wrote:
> Intermittent failures on Windows in a test of destroying the child warrant
> extending the time the parent waits after starting the child before
> destroying the child.
test/jdk/java/lang/ProcessBuilder/Basic.java line 2183:
> 2181:
On Tue, 16 Mar 2021 14:47:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed patch for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8263108?
>>
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and
>>
On Tue, 16 Mar 2021 07:29:34 GMT, Vyom Tewari wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use Chris' suggested solution of avoiding deadlock
>
> Looks good to me.
Holder pattern is easier to understand, I
On Wed, 10 Mar 2021 02:15:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed patch for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8263108?
>>
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and
>>
On Tue, 9 Mar 2021 13:50:05 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed patch for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8263108?
>>
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and
>>
On Sun, 28 Feb 2021 10:28:56 GMT, Attila Szegedi wrote:
>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
>> "AssertionError: Should have GCd a method handle by now"
>
> Attila Szegedi has updated the pull request with a new target base due to a
> merge or a rebase.
On Thu, 25 Feb 2021 15:37:39 GMT, Aleksey Shipilev wrote:
>> Attila Szegedi has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
> The good test would be trying
On Thu, 18 Feb 2021 19:41:21 GMT, Attila Szegedi wrote:
>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
>> "AssertionError: Should have GCd a method handle by now"
>
> @plevart can I bother you for a follow-up review of my original issue?
> (Alternatively,
On Sun, 10 Jan 2021 17:04:19 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>>
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote:
>> Please review this change which fixes the type of the private
>> Reference.discovered field. It was Reference, but that's wrong because
>> it can be any Reference object.
>>
>> I've changed it to Reference and let that flow through,
On Mon, 18 Jan 2021 09:26:07 GMT, Claes Redestad wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett wrote:
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference and let that flow through, updating
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
On Sun, 17 Jan 2021 14:56:40 GMT, Peter Levart wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Simplify lookupCharset
>
> This looks good.
> Are you planning to do similar th
On Sun, 17 Jan 2021 12:07:03 GMT, Claes Redestad wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Sun, 17 Jan 2021 09:03:30 GMT, Peter Levart wrote:
>>> Do you think this code belongs more to String than to StringCoding?
>>
>> I consider StringCoding an implementation detail of String, so I'm not sure
>> there's (much) value in maintaining the separatio
On Sat, 16 Jan 2021 01:02:20 GMT, Claes Redestad wrote:
>> Some common logic is now extracted into methods. That's good. But much of
>> the decoding logic still remains in String. I still think all of static
>> methods can be moved to StringCoding directly as they are now while the
>> private
On Fri, 15 Jan 2021 22:03:31 GMT, Claes Redestad wrote:
>> Hi Claes,
>> This is quite an undertaking in re-factoring!
>> I think that decoding logic that you produced can still be kept in
>> StringCoding class though. The private constructor that you created for
>> UTF-8 decoding is
On Fri, 15 Jan 2021 19:14:06 GMT, Naoto Sato wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Thu, 14 Jan 2021 22:38:53 GMT, Peter Levart wrote:
>> Сергей Цыпанов 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 cont
On Thu, 14 Jan 2021 15:25:25 GMT, Сергей Цыпанов
wrote:
>> Hello, I feel like this was previously discussed in
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
>> find original mail I post this here.
>>
>> Currently `Collections.addAll()` is implemented and
On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart wrote:
>> Hi @stsypanov,
>>
>>> The **behavior** of this convenience method is **identical** to that of
>>> c.addAll(Arrays.asList(elements))
>>
>> What about:
>>
>>>
On Sun, 10 Jan 2021 19:38:11 GMT, Attila Szegedi wrote:
>> Hello Attila,
>> This looks good to me. Just a question: How frequent are situations where
>> the two classloaders are unrelated?
>
>> How frequent are situations where the two classloaders are unrelated?
>
> I think they'd be
On Sun, 10 Jan 2021 17:01:31 GMT, Attila Szegedi wrote:
>> Yes, the pre-initialized fields to Map.of() are safe regardless of whether
>> they are volatile or not (so I would keep them non-volatile to optimize
>> fast-path). Because the BiClassValues instance is published safely to other
>>
On Fri, 8 Jan 2021 16:50:24 GMT, Attila Szegedi wrote:
>> I checked the code of ClassValue and it can be assumed that it publishes
>> associated values safely. The proof is that it keeps values that it
>> publishes assigned to the final field `java.lang.ClassValue.Entry#value`.
>
> So, are you
On Fri, 8 Jan 2021 13:00:16 GMT, Peter Levart wrote:
>>> So what do you think of this variant:
>>
>> I like it. I originally kept the fields volatile so that we don't observe
>> stale values on `getForward`/`getReverse`, but you're right in that even if
On 1/8/21 2:03 PM, Peter Levart wrote:
On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi wrote:
IIUC, your changes mostly all flow from the decision to declare the fields as
non-volatile; if they were still declared as volatile then it'd be impossible
to observe null in them, I think
On Fri, 8 Jan 2021 12:47:17 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>>
On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi wrote:
> IIUC, your changes mostly all flow from the decision to declare the fields as
> non-volatile; if they were still declared as volatile then it'd be impossible
> to observe null in them, I think (correct me if I'm wrong; it seems like you
On Fri, 8 Jan 2021 11:27:57 GMT, Peter Levart wrote:
>> @forax, @plevart could I ask for review once again?
>
> Hi @stsypanov,
>
>> The **behavior** of this convenience method is **identical** to that of
>> c.addAll(Arrays.asList(elements))
>
>
On Fri, 8 Jan 2021 09:37:23 GMT, Сергей Цыпанов
wrote:
>> Apart from the @SuppressWarnings, this looks good to me.
>> And i like the irony of this.
>
> @forax, @plevart could I ask for review once again?
Hi @stsypanov,
> The **behavior** of this convenience method is **identical** to that of
On Fri, 8 Jan 2021 08:49:44 GMT, Attila Szegedi wrote:
>> Hi Attila,
>>
>> This looks good.
>>
>> If I understand correctly, your `BiClassValue` is a holder for a
>> `BiFunction` and a `BiClassValueRoot` which is a
>> `ClassValue`. The `BiClassValues` contains two lazily
>> constructed
On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>>
On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>>
On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis
wrote:
>>> I have to say that introducing a ThreadLocal here seems like a step in the
>>> wrong direction. With a ThreadLocal, if I read this correctly, a
>>> MessageDigest will be cached with each thread that ever calls this API, and
>>> it
On Thu, 31 Dec 2020 10:02:01 GMT, Peter Levart wrote:
> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
This pull request has now been integrated.
Changeset:
ss is loading `Introspector` (which
sets access object)
anyways it might be saner to have this initialization logic in
`SharedSecrets` instead.
Kind regards
Peter Levart hat am 31. Dezember 2020 um 11:07
geschrieben:
On 12/31/20 2:30 AM, Hans Boehm wrote:
It sounds as though this wou
On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber wrote:
>> The bug title and the PR title need to be the same.
>> Editing either one is fine.
>
> But wouldn't it be legal for a compiler (java to bytecode or bytecode to
> machinecode) to replace references of my_local_copy with references to
>
> See: https://bugs.openjdk.java.net/browse/JDK-8259021
> See also discussion in thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
On Sat, 2 Jan 2021 16:28:19 GMT, Johannes Kuhn
wrote:
>> Attila Szegedi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> jtreg runs with assertions on, so using the assert keyword is sufficient
>
> Just a small suggestion using
On 12/31/20 2:30 AM, Hans Boehm wrote:
It sounds as though this would be correct if
if (static_field == null) {
initialize();
}
return static_field;
```
were rewritten as
Foo my_local_copy = static_field;
if (my_copy == null) {
initialize();
my_local_copy = static_field;
}
return
See: https://bugs.openjdk.java.net/browse/JDK-8259021
See also discussion in thread:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
-
Commit messages:
- 8259021 avoid double racy reads from non-volatile fields of SharedSecrets
Changes:
On Tue, 29 Dec 2020 10:42:18 GMT, Peter Levart wrote:
>> Hi,
>> Sorry for joining late to this discussion, but I think that changing this
>> method to delegate to c.addAll(Arrays.asList(...)) might not be the best
>> thing to do here. Why?
>> - This migh
On Tue, 29 Dec 2020 10:21:07 GMT, Peter Levart wrote:
>> "This message" referred to the entirety of that very comment of mine
>> https://github.com/openjdk/jdk/pull/1764#issuecomment-748926986
>>
>> I prepended that message with that clause (that is, the wo
On Mon, 21 Dec 2020 15:23:06 GMT, Pavel Rappo wrote:
>> @pavelrappo also see this not very old comment:
>> https://github.com/spring-projects/spring-framework/pull/24636#pullrequestreview-370684078
>
> "This message" referred to the entirety of that very comment of mine
>
On Fri, 4 Dec 2020 20:16:14 GMT, Mandy Chung wrote:
>> src/java.management/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java
>> line 127:
>>
>>> 125: T got = get();
>>> 126: return got != null && wr.refersTo(got);
>>> 127: }
>>
>> Here you could
On Fri, 4 Dec 2020 20:09:01 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/util/WeakHashMap.java line 293:
>>
>>> 291: // then checks for equality
>>> 292: Object k = e.get();
>>> 293: return key == k || key.equals(k);
>>
>> I think `key == k` is already
101 - 200 of 2148 matches
Mail list logo
