Hi Vladimir,
On 11/05/2014 01:47 PM, Vladimir Ivanov wrote:
Claes,
Thanks for spotting this inefficiency.
New webrev: http://cr.openjdk.java.net/~redestad/8062180/webrev.01
The new code catches the case when a collector is erroneously removed,
but not when a new one is introduced. Can you ex
Hi,
this patch factors out the BoundMethodHandle species data class
generation to a new ClassSpecializer facility.
While currently semantically neutral, this will make it possible
to reuse the facility in other places.
Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/
Bug: https
Thanks Vladimir!
/Claes
On 2017-11-13 17:38, Vladimir Ivanov wrote:
Looks good!
Best regards,
Vladimir Ivanov
On 11/13/17 7:34 PM, Claes Redestad wrote:
Hi,
this patch factors out the BoundMethodHandle species data class
generation to a new ClassSpecializer facility.
While currently
Hi Geoffrey,
since 9 there's MethodHandles.privateLookup(Class, Lookup)[1] to get
hold of a Lookup with the full, private capabilities of a specific
class, as required by LambdaMetafactory.
Replacing line 62 in your sample with the following should work:
MethodHandles.Lookup lookup =
Hi,
thanks for the pointer... :-)
However, while it's true that SVM (in its current form) imposes severe
limits to dynamicity, it'd be a bug if jaotc, jlink or any other of the
startup efforts (such as AppCDS) in the OpenJDK project changed
semantics or imposed limits to indy-style dynamicity