On Thu, 6 Apr 2023 17:50:58 GMT, Chen Liang wrote:
>> It looks like Proxy forcibly adds reads and exports edges from the module of
>> the target interface to the module that defines the proxy:
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/reflect/Proxy.java
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Fri, 7 Apr 2023 12:54:01 GMT, ExE Boss wrote:
> The **JVM** spec doesn’t mention that anywhere though.
I don't think JVMS mentions hidden classes at all. You have to refer to the
specification of Lookup.defineHiddenClass, as hidden classes were originated
from VM anonymous classes added bac
On Fri, 7 Apr 2023 11:41:52 GMT, Johannes Kuhn wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 317:
>>
>>> 315: cob.aload(1);
>>> 316: cob.invokevirtual(CD_MethodHandles_Lookup,
>>> "lookupClass", MTD_Class);
>>> 317:
On Fri, 7 Apr 2023 11:20:12 GMT, ExE Boss wrote:
> that can’t refer to hidden classes
No, that is exactly the **one and only thing** that can refer to the hidden
class:
> * On any attempt to resolve the entry in the run-time constant pool indicated
> by `this_class`, the symbolic reference is
On Thu, 6 Apr 2023 20:47:10 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 19:33:51 GMT, Johannes Kuhn wrote:
>> This is good work.This needs some careful study on the security aspect.
>> I see the proxy class is in the same module of the interface, is non-public,
>> and it has a no-arg non-public constructor.
>>
>> Defining the proxy class i
On Thu, 6 Apr 2023 20:47:10 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 17:56:23 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 213:
>>
>>> 211: .defineClassAsLookup(true, List.of(mhs));
>>> 212: proxy = lookup.findConstructor(lookup.lookupClass(),
>>> meth
On Thu, 6 Apr 2023 20:47:10 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 20:47:10 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Thu, 6 Apr 2023 18:27:33 GMT, Chen Liang wrote:
> I ran with make test TEST="test/jdk/java/lang/invoke/MethodHandleProxies".
> The scratch's subdirectories (corresponding to processors) are all empty.
The contents of the scratch directory is only saved if the test fails. Maybe
it's not that
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 19:22:56 GMT, Mandy Chung wrote:
> This seems a concern if the target method handle should not have access to
> the class in that module.
MethodHandle access is checked when the MethodHandle is created.
For `@CallerSensitive` methods, the MethodHandle is additionally bound
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 18:09:33 GMT, Mandy Chung wrote:
> If you run the test with the system property on, it's dumped in the scratch
> directory. Do you run with jtreg command?
I ran with `make test TEST="test/jdk/java/lang/invoke/MethodHandleProxies"`.
The scratch's subdirectories (corresponding
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Thu, 6 Apr 2023 18:04:49 GMT, Chen Liang wrote:
> It appears the default class hierarchy resolver cannot be used to generates
> stack maps with only the FilePermission required by JTReg granted.
what permission does it need?
-
PR Comment: https://git.openjdk.org/jdk/pull/13197#
On Thu, 6 Apr 2023 17:18:22 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn wrote:
>>> I think it should be possible to spin the class bytes once, stick the
>>> result in a ClassValue cache, but then use the bytes to define multiple
>>> classes with different class data (MethodHandles).
>>
>> Great point, I was dumbfounde
On Thu, 6 Apr 2023 18:03:09 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstanceCall.java
>> line 176:
>>
>>> 174: public void constantLambda() {
>>> 175: i = constantLambda.doWork(i);
>>> 176: }
>>
>> I think setting the resul
On Thu, 6 Apr 2023 17:08:33 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Whitespace, cleanup, rename benchmarks to be informative
>
> test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProx
On Thu, 6 Apr 2023 17:51:27 GMT, Mandy Chung wrote:
>>> The interface access may be problematic: A non-exported interface Class
>>> object can be obtained via Reflection inspection on exported types, such as
>>> java packages and jdk.internal packages.
>>>
>>> * In that case, it might not
On Wed, 5 Apr 2023 13:22:30 GMT, Jorn Vernee wrote:
>> Chen Liang 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
On Thu, 6 Apr 2023 17:27:14 GMT, Jorn Vernee wrote:
>> An other possibility to to add some key into the ClassData that can't be
>> imitated - such as the `InterfaceInfo` itself.
>> An `instanceof` check on the ClassData at a fixed position could then
>> determine if is a MHP.
>
> It looks lik
On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn wrote:
>>> I think it should be possible to spin the class bytes once, stick the
>>> result in a ClassValue cache, but then use the bytes to define multiple
>>> classes with different class data (MethodHandles).
>>
>> Great point, I was dumbfounde
On Thu, 6 Apr 2023 17:18:22 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 17:04:02 GMT, Johannes Kuhn wrote:
>> I don't think that's good enough. If an instance implements an interface
>> that just happens to also have an entry in the INTERFACE_INFOS cache, then
>> e.g. `MethodHandleProxies::wrapperInstanceTarget` could be used to retrieve
>> the
On Thu, 6 Apr 2023 03:44:07 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 17:18:22 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Thu, 6 Apr 2023 16:58:43 GMT, Jorn Vernee wrote:
>> Guess I will just nuke the annotation and check for its implemented clause
>> instead.
>
> I don't think that's good enough. If an instance implements an interface that
> just happens to also have an entry in the INTERFACE_INFOS cache, then
On Thu, 6 Apr 2023 16:24:10 GMT, Chen Liang wrote:
>> Sorry, you are supposed to run it with an installed `SecurityManager` of
>> course.
>> With an installed `SecurityManager` you should not be able to access classes
>> in `sun.misc`.
>
> Guess I will just nuke the annotation and check for i
On Thu, 6 Apr 2023 16:15:16 GMT, Johannes Kuhn wrote:
>> I'm not sure how the example shows that this is a security vulnerability? It
>> still works fine without the call to `isWrapperInstance` (even if you switch
>> to using jdk.internal.misc.Unsafe.class, although that also requires
>> `--ad
On Thu, 6 Apr 2023 16:13:38 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 284:
>>
>>> 282: return
>>> type.getDeclaredAnnotation(WrapperInstance.class);
>>> 283: }
>>> 284: }) : type.getD
On Thu, 6 Apr 2023 15:57:33 GMT, Johannes Kuhn wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Whitespace, cleanup, rename benchmarks to be informative
>
> src/java.base/share/classes/java/lang/invoke/MethodHandlePro
On Thu, 6 Apr 2023 03:44:07 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Wed, 5 Apr 2023 16:30:06 GMT, Jorn Vernee wrote:
> I think this change needs a CSR as well to document the change in behavior.
> If an application currently calls asInterfaceInstance many times for the same
> interface, the amount of classes generated will increase (potentially a lot).
Crea
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Wed, 5 Apr 2023 17:59:24 GMT, Johannes Kuhn wrote:
>>> I think it should be possible to spin the class bytes once, stick the
>>> result in a ClassValue cache, but then use the bytes to define multiple
>>> classes with different class data (MethodHandles).
>>
>> Great point, I was dumbfounde
On Wed, 5 Apr 2023 18:28:15 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 225:
>>
>>> 223: private record LocalMethodInfo(MethodTypeDesc desc,
>>> List thrown) {}
>>> 224:
>>> 225: private record InterfaceInfo(@Stable MethodTyp
On Wed, 5 Apr 2023 13:22:30 GMT, Jorn Vernee wrote:
>> Chen Liang 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
On Tue, 28 Mar 2023 14:34:19 GMT, Chen Liang wrote:
> The interface access may be problematic: A non-exported interface Class
> object can be obtained via Reflection inspection on exported types, such as
> java packages and jdk.internal packages.
>
> * In that case, it might not be of best
On Wed, 5 Apr 2023 04:50:04 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Tue, 28 Mar 2023 10:57:28 GMT, Rémi Forax wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> rethrow error
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
> 206:
>
>> 204: try
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Wed, 29 Mar 2023 00:31:46 GMT, Johannes Kuhn wrote:
>> Do interfaces still implement these properly without definition if they
>> extend interfaces that declare `@Override boolean equals();` etc.?
>
> Yes. You can use [`Comperator`][1] as test.
>
> [1]:
> https://docs.oracle.com/en/java/ja
On Wed, 29 Mar 2023 00:25:09 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 338:
>>
>>> 336: .aload(1)
>>> 337: .ifThenElse(Opcode.IF_ACMPEQ,
>>> CodeBuilder::iconst_1, CodeBuilder::iconst_0)
>>> 3
On Wed, 29 Mar 2023 00:13:56 GMT, Johannes Kuhn wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>>
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Tue, 28 Mar 2023 14:00:41 GMT, Jorn Vernee wrote:
> But this doesn't implement the same ClassValue cache? And spinning byte code
> can indeed be slow (I've seen this in other profiles).
https://github.com/liachmodded/jdk/commit/821d6b382aeceb70c67c59771deb7438f3b4b7fd
I attempted to spin on
On Tue, 28 Mar 2023 14:00:41 GMT, Jorn Vernee wrote:
> I think it should be possible to spin the class bytes once, stick the result
> in a ClassValue cache, but then use the bytes to define multiple classes with
> different class data (MethodHandles).
Great point, I was dumbfounded there.
> L
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Tue, 28 Mar 2023 13:34:05 GMT, Chen Liang wrote:
>
> > I believe you can have better performance if you pass the method handle as
> > the class data of the hidden class and you load it with a constant dynamic
> > [https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/inv
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
On Mon, 27 Mar 2023 23:34:52 GMT, Chen Liang wrote:
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does
As John Rose has pointed out in this issue, the current j.l.r.Proxy based
implementation of MethodHandleProxies.asInterface has a few issues:
1. Exposes too much information via Proxy supertype (and WrapperInstance
interface)
2. Does not allow future expansion to support SAM[^1] abstract classes
66 matches
Mail list logo
