On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart wrote:
>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since
> the entire handle method is `static synchronized` and it is the only method
> that modifies the `h
On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd wrote:
>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not
>> `handlers.replace(...)`? And yes, I think what you suggest will help remove
>> the synchronized block here.
>
> Oops, yes you are correct!
Hi,
I think the
On Wed, 25 May 2022 15:54:04 GMT, Maxim Kartashev
wrote:
>> `CgroupV1Subsystem.getInstance(...)` also claims that it never returns
>> `null`, but has a code-path that actually returns `null` (when there is no
>> active controller). Is this a possible outcome?
>
> @plevart Are you asking about
On Wed, 25 May 2022 14:39:42 GMT, Peter Levart wrote:
>> Following the logic from the comment directly above the changed line, since
>> it doesn't matter which controller we pick, pick any available controller
>> instead of the one called "memory" specifica
On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev
wrote:
> Following the logic from the comment directly above the changed line, since
> it doesn't matter which controller we pick, pick any available controller
> instead of the one called "memory" specifically. This way we are guarded
>
Hi,
On 23/05/2022 14:53, Brian Goetz wrote:
...
Are there any useful Consumer> in the wild, that are
actually typed like that? I doubt it (there are many things
convertible to it, though.) Which suggests it might be fruitful to
define a FI:
interface PushSource {
void
On Sun, 22 May 2022 16:54:25 GMT, Peter Levart wrote:
> My humble opinion: if java.compiler needs jdk.zipfs for full functionality
Sorry, I wrongly assumed it was `java.compiler` (the library module), but this
is about `jdk.compiler` (the tool)... Nevertheless, the same question appl
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote:
>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its
>> dependencies
>> fails to run java source launcher correctly (for example when --source N is
>> specified).
>> Failing source
On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote:
>> Improving the exception messages for out-of-supported-range array types.
>>
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy wrote:
> > The mapping from Location to AccessFlag(s) could be implemented event
> > without using a Map. You just have to be careful not to use EnumSet for
> > that (i.e. before AccessFlag enum constants are fully initialized) - an
> > ArrayList is
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Mon, 28 Feb 2022 18:20:13 GMT, ExE Boss wrote:
>> It does because of the AccessFlags.MODULE constant.
>
>> It does because of the AccessFlags.MODULE constant.
>
> But that’s exactly what the unqualified `MODULE` identifier refers to, and
> there’s no other bare `MODULE` identifier in scope
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
On Mon, 17 Jan 2022 08:28:35 GMT, Erik Gahlin wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405:
>>
>>> 403: Object res = m.invoke(a, new Object[0]);
>>> 404: if (res instanceof Annotation[]) {
>>> 405:
On Mon, 21 Feb 2022 16:35:09 GMT, liach wrote:
>> liach 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 contains 13 additional commits since
>> the last
On Fri, 11 Feb 2022 21:44:04 GMT, Mandy Chung wrote:
> Note that the object methods of this Config record are called via indy which
> is
> available to use after initPhase1. We can workaround that limitation by
> implementing the object methods.
"Note that the object methods of this Config
On Fri, 11 Feb 2022 13:42:01 GMT, liach wrote:
>> ...having suggested that rearrangement, perhaps the right way to do it is to
>> enable some VM.isXXX queries themselves to be constant-foldable so that
>> other callers too may benefit. Like this:
>>
On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote:
>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
>> by design, duplicate initialization of ReflectionFactory should be safe as
>> it performs side-effect-free property read actions, and the suggesting of
>> making
On Fri, 11 Feb 2022 08:05:30 GMT, Peter Levart wrote:
>> liach has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Make config a pojo, move loading code into config class
>
> src/java.base/shar
On Thu, 10 Feb 2022 22:53:56 GMT, liach wrote:
>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
>> by design, duplicate initialization of ReflectionFactory should be safe as
>> it performs side-effect-free property read actions, and the suggesting of
>> making
On Thu, 10 Feb 2022 13:36:11 GMT, liach wrote:
>> liach 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 contains seven additional commits
>> since the
On Sat, 22 Jan 2022 00:00:18 GMT, liach wrote:
>> liach 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 contains four additional commits since
>> the
On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote:
> Note this matches other places we do the weak-reference loops, for example in
> `MethodType`:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401
This one does
On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev wrote:
> > So, this patch is fine for making ClassCache more robust as a re-usable
> > component inside JDK (checking for non-null return of computeValue). The
> > 2nd change, that apparently shields against unbounded accumulation of
> >
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Fri, 10 Dec 2021 21:07:37 GMT, Roman Kennke wrote:
>> As a follow-up to #6375, this change refactors
>> java.io.ObjectInputStream.Caches#subclassAudits and
>> java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead
>> of SoftReference, similar to what we did in #6375 for
On Mon, 6 Dec 2021 12:12:44 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Thu, 2 Dec 2021 16:22:02 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Thu, 2 Dec 2021 14:24:06 GMT, Roman Kennke wrote:
>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:
>>
>>> 2131: if (oldReflector != null) {
>>> 2132: reflector = oldReflector;
>>> 2133: }
>>
>> Map.computeIfAbsent(key, () ->
On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get
On Mon, 29 Nov 2021 13:47:19 GMT, Roman Kennke wrote:
> I don't quite understand this: If the Class object is still reachable by the
> app,
1. a weak reference would not get cleared and
2. the Class's ClassLoader would not get unloaded.
...but the ObjectStreamClass instance could still get
On Mon, 15 Nov 2021 19:10:17 GMT, Roman Kennke wrote:
> > If the intent of this change is to alter the lifetimes of the objects in
> > question in a meaningful way, I recommend a CSR for the behavioral
> > compatibility impact.
>
> It would be hard for application code to observe this change:
On Thu, 18 Nov 2021 14:53:38 GMT, Peter Levart wrote:
>> I think @shipilev asks a good question. This could be done completely in the
>> VM without the changes to j.l.ref.Finalizer. The CLI option is for
>> experimenting, at least in the short term, and should
On Thu, 18 Nov 2021 08:39:52 GMT, Alan Bateman wrote:
>> Yeah, "flag" is `Holder.ENABLED` here. I mean, are Java methods
>> `registerFinalizer` and `runFinalization` called only by VM? If so, can VM
>> check the whole thing on VM side, without going to Java and asking back from
>> there?
>
>
On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote:
> Currently, when the stream holds a resource, it's necessary to wrap it with
> try-with-resources. This undermines the compact and fluent style of stream
> API calls. For example, if we want to get the `List` of files inside the
>
Hi,
On 11/10/2021 20:42, John Rose wrote:
To summarize: We can (and should) try to model “close-debt”
using interfaces. Doing so opens up the usual cans of worms
with interoperability and exceptions, but still gives us a
model we can contemplate. We can (and should) contemplate
how such a
On Thu, 14 Oct 2021 16:05:19 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java
>> line 86:
>>
>>> 84: }
>>> 85:
>>> 86: private static final int PARAM_COUNT_MASK = 0x00FF;
>>
>> Is this packing logic required? I get it that it
On Tue, 12 Oct 2021 17:42:01 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix left-over assignment
>
> src/java.base/shar
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote:
> This patch improves reflective access speed as shown by the included
> benchmarks:
>
> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>
> ... and is also a prerequisi
On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote:
>> This patch improves reflective access speed as shown by the included
>> benchmarks:
>>
>> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>>
>> ... an
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Add Constructor benchmarks
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5694/files
- new: https://git
On Sat, 2 Oct 2021 15:31:35 GMT, Peter Levart wrote:
> > I'm fine with going back to the previous iteration. I'd add `@Stable` to
> > the same fields in `Constructor`, too, though.
>
> Good catch. I'll add @stable to select Constructor fields. They are important
> for o
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
More @stable fields in Constructor/Field to align them with Method fields
-
Changes:
- all: https://git.openjdk.j
t; with Method Handle) perform better in some circumstances.
Peter Levart 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.
-
Changes:
- all: https://git.open
On Tue, 28 Sep 2021 22:41:23 GMT, Claes Redestad wrote:
> I'm fine with going back to the previous iteration. I'd add `@Stable` to the
> same fields in `Constructor`, too, though.
Good catch. I'll add @stable to select Constructor fields. They are important
for optimizing `Const` use cases.
On Tue, 28 Sep 2021 09:50:45 GMT, Claes Redestad wrote:
> Does `Reflection::new_method/...` (which are natively implemented
> constructors) need any special treatment for them to follow the same
> semantics as a Java-based constructor w.r.t. final field writes? Or could
> they be rewritten to
On Mon, 27 Sep 2021 19:59:00 GMT, Mandy Chung wrote:
> A stray thought is why not most fields in `Field`/`Method`/`Constructor` are
> `final`, as my IDE suggests. I can't find any hotspot code that injects
> values to these fields. Experimentally changing most fields in `Field` to
> final
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Make Method/Constructor/Field instance fields initialized in the constructors
final
-
Changes:
- all: https://git
On Mon, 27 Sep 2021 17:31:50 GMT, Mandy Chung wrote:
> Looks good to me. Very nice performance improvement.
>
> One minor comment: I think the change in `UnsafeFieldAccessorImpl.java` and
> `UnsafeStaticFieldAccessorImpl.java` isn't necessary since they're final
> fields. It can be reverted.
This patch improves reflective access speed as shown by the included benchmarks:
https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection
with Method Handle) perform better in
On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad wrote:
> > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for
> > each instance of Method/Field does not help at all.
>
> The added indirection in the "Poly" test might cause the code to fall off the
> inlining cliff, so
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
t of `MethodHandle.asType()` conversion can't populate the higher level
>> cache.
>>
>> The fix is based on [the
>> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
>> made by Peter Levart @plevart back in 2015.
>>
>>
t of `MethodHandle.asType()` conversion can't populate the higher level
>> cache.
>>
>> The fix is based on [the
>> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
>> made by Peter Levart @plevart back in 2015.
>>
>>
On Sat, 7 Aug 2021 02:07:24 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart wrote:
>> src/java.base/share/classes/java/lang/Runtime.java line 662:
>>
>>> 660: * or that any particular number of {@link java.lang.ref.Reference
>>> Reference}
>>> 661: * object
On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Ru
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. reference
offering it
> in this pull request without any changes to the JVM behavior.
To share the information... I contacted one of the original authors of Java
annotations, but he doesn't remember anything about the option. Here's the
conversation...
On Thu, Jun 3, 2021 at 11:53 PM Peter L
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
viors not consistent with tar will make it a strange
hybrid. Trying to find common ground with other JDK tools will make it
less flexible.
Regards, Peter
On 29/06/2021 09:05, Peter Levart wrote:
Hi,
On 29/03/2021 12:46, Jaikiran Pai wrote:
Given the support of -C/-dir is new and -P is
Hi,
On 29/03/2021 12:46, Jaikiran Pai wrote:
Given the support of -C/-dir is new and -P is there for backwards
compatibility then I see the choices are:
* Issue an error when -P and -C/-dir are specified together with -x
* Silently ignore the -P option
* Ignore -C/-dir and the behavior
. Now how does
ByteBuddy come into this picture? What does it do with code that either
uses AccessController API and what would it have to do with code that
uses AccessControllerWrapper instead?
Regards, Peter
Am Di., 15. Juni 2021 um 09:20 Uhr schrieb Peter Levart
mailto:peter.lev
Hi Rafael,
On 13/06/2021 22:28, Rafael Winterhalter wrote:
Furthermore, it is difficult to create a working facade for dispatching to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a utility
to a library, this utility
On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the
On 02/06/2021 19:24, Rémi Forax wrote:
I foolishly hoped that nobody would subclass a class with `Immutable` in its
name,
oh boy i was wrong:)
There's nothing wrong in subclassing an immutable class. As long as the
subclass keeps being immutable. Was it subclassed and made mutable by
On Thu, 3 Jun 2021 07:31:14 GMT, David Holmes wrote:
> > > The code is confusing because it gives no indication that it is aware
> > > that runtime invisible annotations could be present:
> > > /**
> > > * Parses the annotations described by the specified byte array.
> > > * resolving constant
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On Wed, 2 Jun 2021 22:47:13 GMT, David Holmes wrote:
> On 3/06/2021 2:54 am, Joe Darcy wrote:
>
> > If the reflection runtime doesn't implement the semantics of
> > -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that
> > option now.
>
> I have to agree with Joe now. I
On Wed, 2 Jun 2021 22:44:10 GMT, David Holmes wrote:
> > I think this is not deliberate. Since `rawAnnotations` may end up having
> > any of the following:
> > - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation
> > usages compiled into the class or
On Wed, 2 Jun 2021 16:56:07 GMT, Joe Darcy wrote:
> If the reflection runtime doesn't implement the semantics of
> -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that
> option now.
>
> -Joe
What is the -XX+PreserveAllAnnotations semantics in terms of reflection? The VM
spec
On Wed, 2 Jun 2021 13:24:10 GMT, David Holmes wrote:
> Sorry now I see what happens. We aren't combining two arrays of
> annotations we're concatenating two streams of byes, each of which
> represents a set of annotations, starting with the length.
>
> The code that receives this on the JDK
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On Wed, 2 Jun 2021 05:59:05 GMT, David Holmes wrote:
> Sorry Jaroslav but I don't really see this test as a basic functional
> test of the PreserveAllAnnotations flag. There is no need for any
> dynamic retention mode switch. All you need as I've said previously is a
> class with all the CLASS
On Wed, 2 Jun 2021 12:33:37 GMT, Peter Levart wrote:
> I suggest the following patch for the bug in AnnotationParser:
>
An alternative would be to change the `ClassFileParser::assemble_annotations`
in the VM to no be so "dumb", but to construct correct concatenation.
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart wrote:
>> ...hm, it seems that mere presence of any RUNTIME annotation that was
>> RUNTIME already at the use compile time somehow affects
>> -XX:+PreserveAllAnnotations option so that now RUNTIME annotations that were
>>
On Wed, 2 Jun 2021 11:34:18 GMT, Peter Levart wrote:
>> test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java
>> line 81:
>>
>>> 79: " should not be visible at runtime");
>>> 80: }
>
On Wed, 2 Jun 2021 10:36:06 GMT, Peter Levart wrote:
>> There doesn't seem to be much support for the complete changes in #4245. To
>> get at least something useful from that endeavor I have extracted the test
>> for existing behavior of `-XX:+PreserveAllAnnotations`
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
>
On 01/06/2021 22:28, John Rose wrote:
On Jun 1, 2021, at 7:02 AM, Brian Goetz
mailto:brian.go...@oracle.com>> wrote:
As Alan's archaeology discovered, this flag appears to be a leftover from the
original implementation, and I could find no signs of its usage.
Note to self and other
1 - 100 of 2148 matches
Mail list logo
