Root cause:
Cached in ClassValue values are prohibited to reference any java.lang.Class or ClassValue instances as they are considered as strong roots that prevent Class and ClassValue garbage collection,
creating effectively unloadable cycle.
This problem is also known as JDK-8136353.
Actions taken:
* Extract anonymous ClassValue instance into a separate static class that does not capture anything implicitly
* Wrap cached values in ClassValue into SoftReference to avoid unloadable cycles
^KT-56093 Fixed
Using `ReflectionProperties.lazy` is incorrect because it allows several
threads to observe different resulting values if they're computing it
simultaneously (unlike `lazy(PUBLICATION)`, which always returns the
value that "won the race").
In the case of property delegates, for example, if we're invoking
`isAccessible = true` and then `getDelegate()` concurrently, it might
happen that when some thread invokes `getDelegate()`, it gets the
underlying Field object which was written by another thread and which
has not yet been made accessible, leading to
IllegalPropertyDelegateAccessException.
#KT-27585 Fixed
- Make the implementations very similar, to fix KT-54833 where the
companion object case was forgotten for kotlinProperty.
- Optimize both functions to look up the function/property by name
first, to cover the most probable case when the JVM name of a
declaration is equal to its Kotlin name. This fixes KT-55937.
#KT-54833 Fixed
#KT-55937 Fixed
Since KT-53308, we started to cache results of typeOf invocation
in reflection. The cache uses the origin 'KClassifier' as a key with
an optional list of 'KTypeProjection' in type argument position,
and computed result as a value.
Without classifier check, the caching produces incorrect execution in
a very specific classloaders usage which is leveraged
by IDEA source-tree:
* All Kotlin stdlib and reflect classes are always loaded by the same
classloader
* Other classes that depend on Kotlin are loaded by separate
classloaders
The reproducer:
* Attempt to use typeOf<kotlin.List<Foo>> from one classloader caches
the resulting KType
* Attempt to use typeOf<kotlin.List<Foo>> from another classloader
for the same 'Foo' that differs only in classloader reuses the
computed KType, meaning that KType type argument classifier
is simply incorrect and points to the 'Foo' from the first classloader
#KT-54611 Fixed
#KT-54629 Fixed
Merge-request: KT-MR-7470
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
This is related to 8308f5d7d3 (KT-44977).
It turns out that it's necessary to create `ArrayValue` with a
precomputed type not only in case of annotations stored directly in
Kotlin metadata (i.e. annotations on types and type parameters), but
also for arguments of repeated annotations. The reason is that repeated
annotations are stored in an array themselves, as an argument to another
(container) annotation. The annotation-reading code unwraps this array
to load repeated annotations as individual instances of
`AnnotationDescriptor`, but in contrast to loading normal annotations,
it doesn't set `source` to the reflection object, it uses `NO_SOURCE`
(see BinaryClassAnnotationAndConstantLoaderImpl.AbstractAnnotationArgumentVisitor.visitArray).
So when kotlin-reflect is later asked for the arguments of the
annotation, it needs to recreate the reflection object from
`AnnotationDescriptor` in `util.kt`. Doing so requires knowing the array
type, which is now present because we're creating a `TypedArrayValue`
(previously `DeserializedArrayValue`) in places where arrays are read as
annotation arguments.
Alternative solution would be to fix source passed to
`AnnotationDescriptorImpl` in the annotation-reading code, but that
seems a bit messy because the code is very abstract and is used in lots
of other places.
#KT-53279 Fixed
* Cache KType instances constructor from the given classifier
* For generics, cache KTypes with already substituted arguments
* It significantly speeds up all typeOf-based APIs, both accesses to typeOf and its related properties (i.e. classifier)
#KT-53508
Merge-request: KT-MR-6818
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
* It is a heavy-weight object that is hard to compute
* It is being constructed each type _cached_ method ref is used in equals/hashCode
* Module name is deliberately ignored, corresponding doc is added where appropriate
#KT-48136
Merge-request: KT-MR-6817
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
* Replace pcollections with ClassValue/ConcurrentHashMap-based caches
* Do not store weak references, instead cache strong references and count on ClassValue to unload the corresponding classloader if necessary
* ConcurrentHashMap does not rely on WeakReference as it's only selected on Android where classloader leaks don't exist
* Update reflect/scripting JDK requirement to Java 8 in order to proceed
#KT-53454
#KT-50705
Merge-request: KT-MR-6788
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
The proper support will come in KT-15518, but that would be a breaking
change even for stable Kotlin without kotlin-reflect. Before that issue
is fixed, represent Nothing in types with the Void class, and use a flag
in the no-reflect implementation to remember that it's not actually the
Void class itself.
#KT-39166 Fixed
This function was always experimental, as explained in its kdoc, but it
was introduced before opt-in requirement markers were supported. Thus,
breaking changes (such as in KT-42746) were always expected, and the
`@ExperimentalReflectionOnLambdas` annotation just makes it clearer.
#KT-45486 Fixed
Although the previous code of computing JVM internal name from a Class
instance was shorter, it led to unnecessary creation of array types,
which is less performant and makes configuration of kotlin-reflect for
GraalVM native-image more verbose.
Unfortunately I didn't succeed in writing a test for this, since
`Array.newInstance` calls a native method which doesn't record any trace
of it being called in the class loader: the resulting array type never
goes through findClass/loadClass, and is not visible via
findLoadedClass.
#KT-44594 Fixed
For the same reason as in the previous commit: descriptors are cached
via weak references in moduleByClassLoader.kt and can be
garbage-collected at any point. So different instances of KParameterImpl
representing the same parameter may store different instances of
descriptors.
Descriptors are cached via weak references in moduleByClassLoader.kt and
can be garbage-collected at any point. So relying on identity of
descriptors in KTypeParameterImpl is dangerous because the same type
parameter can be represented by different descriptors. For example, the
test equalsOnFunctionParameters.kt was flaky before this change because
of this issue, and that could be reproduced by running it a few hundred
times in the same process.
Instead, use the type parameter's container (which is either KClass or
KCallable) and name, in equals/hashCode. KClass and KCallable already
have equals/hashCode independent of descriptors, so this works in case
the descriptor is invalidated.
Vsevolod Tolstopyatov