Hidden classes + class data
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Nov 26 23:03:52 UTC 2019
----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "mandy chung" <mandy.chung at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Vendredi 22 Novembre 2019 18:00:35
> Objet: Re: Hidden classes + class data
> When we have frozen arrays, this is solved by freezing the array, which is a
> no-op if the array is already frozen.
or wait until we have having a real class templating mechanism because passing a class data object is a de-generate case of class templating with a kiddy pool containing only one Object.
I wonder if defineHiddenClassWithClassData should not take another class as parameter instead of a byte array (using the byte array of that class) enabling more sharing of the bytecode and allowing to do the verification only once if defineHiddenClassWithClassData is called several times with the same Class.
>> On Nov 22, 2019, at 11:56 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> On 11/22/19 6:57 AM, Remi Forax wrote:
>>> Hi Mandy,
>>> hi all
>>> I've played a little with the nestmates branch, trying to see how to
>>> re-implement the reflection API based on the method handle API.
>>> A question, correct me if i'm wrong but every hidden classes has its own
>>> bytecode array even when i call defineHiddenClassWithClassData several times
>>> with the same byte array ?
>> Yes it does. It clones the given byte array to avoid it might be modified after
>> any kind of validation. Lookup::defineClass does the clone too. Perhaps we
>> have to rethink about the security aspect vs the overhead of cloning?
>>> Also, is it possible to have a Lookup.defineClass variation that takes a class
>>> data as parameter but do not create a hidden class, something like
>>> Class<?> defineClassWithClassData(byte bytes, Object classData, boolean
>>> It would be very convenient in order to generate a something like a lambda body
>>> (not the lambda adapter/proxy) where you want it to appear in th stacktrace
>>> because it's a code produced by a user.
>> Does this also need access to its nestmate? Our intent is to limit the dynamic
>> nestmates to hidden classes as the current scope for this work. Separate
>> the extension of dynamic nestmates to ordinary classes in the future.
> > Mandy
More information about the valhalla-dev