Hi Claes,
Your changes look good. But I spotted a pre-existing and unusual use of
@Stable annotation in java.lang.invoke.MethodTypeForm class:
// Cached adapter information:
@Stable final SoftReference[] methodHandles;
// Cached lambda form information, for basic types only:
f
Hi Joe,
I've been thinking of this example:
83 final class Ser implements Externalizable {
84
...
99 /** The object being serialized. */
100 @SuppressWarnings("serial") // Not statically typed as
Serializable
101 private Object object;
Externalizable does extend Serializa
Once more, for the list (sorry)...
Hi,
On 9/21/19 12:31 PM, Chris Hegarty wrote:
Roger,
On 20 Sep 2019, at 19:51, Roger Riggs wrote:
Please review code cleanup that will remove the need to suppress soon
to be introduced
warnings [1] about static typing of serialization related fields.
A f
On 9/25/19 12:15 PM, Remi Forax wrote:
that said, i believe we should deprecate LinkedList (and any other List
implementation that doesn't implement RandomAccess) because there are too much
code out there that suppose that list.get() is O(1).
Hi Remi,
Deprecating LinkedList as a whole is may
Hi Ivan,
On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
If the list is malformed, then the constructors throw
IllegalArgumentException.
It turns out that the current i
Hi Joe,
On 10/3/19 5:32 PM, Joe Darcy wrote:
Hello,
In response to the recent and on-going review of serializable types in
the base module and elsewhere, I thought it would be helpful if the
collections specs discussed how collections were serialiazable. In
particular, the proposed terminolo
Oh god, a typo in a typo comment... I better go to sleep now ;-)
On 10/4/19 11:14 PM, Peter Levart wrote:
+ * serialized. Otherwise, is one or more objects in a collection are
s/is/in/
s/is/if/
Peter
Hi Stuart,
I also prefer your wording. There's just a nit...
On 10/5/19 1:46 AM, Stuart Marks wrote:
On 10/3/19 8:32 AM, Joe Darcy wrote:
In response to the recent and on-going review of serializable types
in the base module and elsewhere, I thought it would be helpful if
the collections sp
Hi Ogata,
May I just add that volatile field ensured that MethodAccessor object
was correctly published. DelegatingMethodAccessortImpl is not safe to be
published via data race because it contains plain `delegate` field
initialized in the constructor. In addition, the object that is first
ass
On 10/8/19 8:37 PM, Claes Redestad wrote:
On 2019-10-08 18:57, Kazunori Ogata wrote:
Hi Claes,
Thank you for your review and comment.
I was also wondering why only these two fields aren't initialized in the
constructor. Shall I also make the change you mentioned?
I think it might be be
= 2331 ms (+106%)
webrev.04: Elapsed time = 3746 ms (+ 28%)
I'll measure larger benchmark and try to think if we can reduce the
overhead of memory barrier.
Regards,
Ogata
Peter Levart wrote on 2019/10/09 16:44:13:
From: Peter Levart
To: Kazunori Ogata , core-libs-dev@openjdk.java.net
Hi Hamlin,
in TCPTransport.decrementExportCount():
283 try {
284 if (tcpLog.isLoggable(Log.BRIEF)) {
285 tcpLog.log(Log.BRIEF, "close server socket on
" + ss);
286 }
287 ss.close();
288 } catch (I
Hi Mandy,
http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.03/
In Lookup's findBoundCallerClass and checkSecurityManager the javadoc is
still talking about private access only although the checks are now made
against full privilege access.
Some possible nano optimization / simpli
Hi Maurizio,
Nice work!
I see the API prefixes each independent access to memory with a call to
the following MemorySegmentImpl method:
157 @Override
158 public final void checkValidState() {
159 if (owner != Thread.currentThread()) {
160 throw new IllegalState
Hi,
On 12/2/19 6:13 PM, Bob Vandette wrote:
2)
How should we deal with "not supported" for booleans/arrays, etc.?
Would it make sense to return record objects from the Metrics API so
that this could be dealt with? E.g.
Metrics m = ...
MetricResult result = m.getCpuSetCpus();
switch(result.getTy
Hi Seán,
WeakHashMap is not safe to be called concurrently. Even get() method,
although it may seem read-only, can modify internal state (expunging
stale Weak entries), so holding a READ lock while accessing WeakHashMap
it is wrong.
getInitialContext() static method is called with an env Has
On 1/30/20 8:59 AM, Peter Levart wrote:
So if you know that the (implementation class of)
InitialContextFactory instance is always resolvable (by class name)
from the ClassLoader you are using for the caching key (the TCCL),
then this utility might be just right for your purpose.
Thinking
d
approach
* insert use of sleep which testing GC.
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
regards,
Sean.
On 30/01/2020 07:59, Peter Levart wrote:
Hi Seán,
WeakHashMap is not safe to be called concurrently. Even get() method,
although it may seem read-only, can modify interna
Hi Seán,
On 2/1/20 12:22 AM, Seán Coffey wrote:
The following is also possible:
// 1st try finding a ServiceLoader.Provider with type()
of correct name
factory = loader
.stream()
.filter(p -> p.type().getName().equals(className))
o - I'm hoping to port this to JDK 11u also so I might spin the
specification changes into a different bug ID.
regards,
Sean.
On 03/02/2020 09:05, Peter Levart wrote:
Hi Seán,
On 2/1/20 12:22 AM, Seán Coffey wrote:
The following is also possible:
// 1st try finding a Ser
On 2/5/20 12:53 PM, Peter Levart wrote:
On 2/5/20 9:31 AM, Seán Coffey wrote:
Thanks again for the review Peter. There's an off-thread conversation
around whether the ClassLoaderValue should hold SoftReferences to the
Factory that's stored with the classloader. I think we
On 2/5/20 2:46 PM, Alan Bateman wrote:
On 05/02/2020 11:53, Peter Levart wrote:
:
Please, include me in the conversation. I would like to know whether
this is really possible, because I think it is not. If the
implementation class / provider type is resolved using thread's
context
On 2/6/20 6:54 PM, Seán Coffey wrote:
the current proposal is still:
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
But wasn't this one already better:
https://cr.openjdk.java.net/~coffeys/webrev.8223260.v3/webrev/
Or do you prefer the v2 so that spec change and behavior cha
On 2/7/20 12:11 AM, Seán Coffey wrote:
On 6 February 2020 21:13:52 GMT, Peter Levart wrote:
On 2/6/20 6:54 PM, Seán Coffey wrote:
the current proposal is still:
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
But wasn't this one already better:
https://cr.openjdk.jav
Hi Claes,
I hope I'm not to late to comment on this. This change is ok as it
stands, but I'm afraid it is not in the spirit of Valhalla. As I
understand, you rely on the fact that Integer instances in the low range
of values are cached and you then use identity comparison in the
following met
Hi Roger,
What about deprecating this method (not for removal at this time) and
creating new method UUID.valueOf(String) or similar that would be more
strict?
Peter
On 3/6/20 7:15 PM, Roger Riggs wrote:
Hi Chihiro, et.al.,
Thanks for taking a look at this issue, however...
There has been
On 3/8/20 8:45 AM, Peter Levart wrote:
Hi Roger,
What about deprecating this method (not for removal at this time) and
creating new method UUID.valueOf(String) or similar that would be more
strict?
... since Andriy Plokhotnyuk and Claes Redestad have already done all
the coding (nice
On 3/8/20 9:28 AM, Peter Levart wrote:
I can imagine bugs are a possible outcome when a programmer doesn't
realize that different String values can successfully map to a single
UUID value.
Well, this is still true even with the strict method (since 'a'...'f' is
e
Hi,
When I noticed this optimization, I had some ideas how to push this even
further, but only now had some time to try them out.
Here are some incremental improvements [1] to the already brilliant idea
with the following JMH results (the baseline is JDK build with patch for
8196334 already
.
Sorry for noise.
Regards, Peter
On 3/8/20 12:46 PM, Peter Levart wrote:
Hi,
When I noticed this optimization, I had some ideas how to push this
even further, but only now had some time to try them out.
Here are some incremental improvements [1] to the already brilliant
idea with the
Hi Mandy,
Good work.
I'm trying to find out which language use-case is covered by the
InnerClassLambdaMetafactory needing to inject method handle into the
generated proxy class to be invoked instead of proxy class directly
invoking the method:
useImplMethodHandle =
!implClass.getPa
}
...I would draw the conclusion that conversion to lambda is performed in
less cases not in more. Hm.
Regards, Peter
On 4/3/20 11:11 AM, Peter Levart wrote:
Hi Mandy,
Good work.
I'm trying to find out which language use-case is covered by the
InnerClassLambdaMetafactory needing to
/20 4:40 AM, Peter Levart wrote:
Ok, I think I found one such use-case. In the following example:
package test;
public class LambdaTest {
protected void m() {
}
}
package test.sub;
public class LambdaTestSub extends test.LambdaTest {
public void test() {
Runnable r = this::m
Peter
On 4/4/20 12:58 PM, Peter Levart wrote:
Hi Mandy,
On 4/3/20 11:32 PM, Mandy Chung wrote:
Hi Peter,
I added a JBS comment [1] to describe this special case trying to put
the story together (let me know if it needs more explanation). More
comment inline below.
Thanks, this helps in es
On Wed, 28 Oct 2020 20:13:19 GMT, Rémi Forax
wrote:
>> Hi Remi,
>>
>> I appreciate your proposal to modernize Proxy API. There are several
>> requests for this enhancement to support default methods in Proxy.
>> Defining a new `java.lang.invoke.Proxy` is a much bigger project that I
>> c
On Fri, 20 Nov 2020 10:55:21 GMT, Peter Levart wrote:
>> The trick is that if we know that a class like java.lang.invoke.Proxy may
>> exist,
>> it means that instead of distorting the j.l.r.Proxy API to increase of few
>> percents the performance when calling a defa
On Fri, 20 Nov 2020 20:14:23 GMT, Mandy Chung wrote:
>> Hi Mandy,
>> thanks for taking the time to explore all the different options,
>>
>> The solution 1 is fine for me.
>
> Thanks Remi.
I agree solution 1 is the best after all things considered.
-
PR: https://git.openjdk.java.ne
On Tue, 24 Nov 2020 03:46:38 GMT, Stuart Marks wrote:
>> In `ReferencePipeline` class we have:
>>
>> @Override
>> public final Object[] toArray() {
>> return toArray(Object[]::new);
>> }
>>
>> @Override
>> @SuppressWarnings("unchecked")
>> public final A[] toArr
On Wed, 25 Nov 2020 14:07:07 GMT, Peter Levart wrote:
>> This is the default implementation in the Stream interface, which is
>> overridden by an implementation in the ReferencePipeline class, so it will
>> rarely be used in normal operation. The ReferencePipeline version
On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote:
> Concurrent updates may lead to redundant LambdaForms created and unnecessary
> class loading when those are compiled.
>
> Most notably, it severely affects MethodHandle customization: when a
> MethodHandle is called from multiple thre
On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov wrote:
> Concurrent updates may lead to redundant LambdaForms created and unnecessary
> class loading when those are compiled.
>
> Most notably, it severely affects MethodHandle customization: when a
> MethodHandle is called from multiple thre
On Tue, 1 Dec 2020 10:05:04 GMT, Peter Levart wrote:
>> Concurrent updates may lead to redundant LambdaForms created and unnecessary
>> class loading when those are compiled.
>>
>> Most notably, it severely affects MethodHandle customization: when a
>> Method
On Tue, 1 Dec 2020 15:45:45 GMT, Peter Levart wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1783:
>>
>>> 1781: } finally {
>>> 1782: updateInProgress = false;
>>> 1783: }
>>
&g
age of a dynamic module.
>>
>> The spec change is that a proxy class used to be defined in an unnamed
>> module, i.e. in a exported and open package, is defined in an unconditionally
>> exported but non-open package. Programs that assume it to be open
>> unconditio
On Wed, 2 Dec 2020 11:37:07 GMT, Vladimir Ivanov wrote:
>> I mean, is it possible that some threads that concurrently use the old
>> uncustomized form while one thread is customizing it, trigger JIT
>> compilation and because `form` field is trusted final, the JITed code will
>> be using the u
On Wed, 2 Dec 2020 14:30:57 GMT, Peter Levart wrote:
>> Thanks for the review, Peter.
>> The contract of `updateForm` clearly states that there are no guarantees
>> provided about visibility:
>> /**
>> * Replace the old lambda form of this method handle
On Wed, 2 Dec 2020 15:24:47 GMT, Vladimir Ivanov wrote:
>> Would it make a difference if MH.form was not final and each read access to
>> it was done via appropriate Unsafe.getReferenceXXX()?
>
>> Would it make a difference if MH.form was not final and each read access to
>> it was done via app
On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote:
> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
> avoid keeping a referent strongly reachable that could cause unnecessary
> delay in collecting such object. I only made change in some but not all
> classes i
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 cov
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 pre
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
> https://github.com/ope
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 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 might look a
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: https://git.o
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
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 `MethodHa
> 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:
r
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
>
t class 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 would
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:
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 won
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.
>> Neithe
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.
>> Neithe
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 Map(s
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 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))
>
> What about
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 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.
>> Neithe
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
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 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 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
>> thr
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 extremely
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:
>>
>>> The **behavio
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 documen
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 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
>> overhead
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 unnecessary
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 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
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
>> over
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 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 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 so
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
>> over
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, updati
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.
>> Neith
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, @shipilev
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 wi
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. T
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
>> `java.lang.constant.Constan
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
>> `java.lang.constant.Consta
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 agre
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
>> `java.lang.constant.Consta
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 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 it
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 class
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 underlying
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 wa
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
&
101 - 200 of 2235 matches
Mail list logo
