Hi Ahmed,
This is not a problem. When there are no properties, property count is
zero now (previously miscalculated!). Where there are zero properties,
no need to create a new PropertyMap - PropertyMap in ScriptFunctionImpl
can be reused for such cases and hence you see the variant without
PropertyMap being invoked (as it should be).
-Sundar
On Sunday 21 June 2015 03:11 PM, Ahmed Ashour wrote:
Hi Sundar,
I am not sure if this is an issue or not, but with manual applying of the patch
to the jdk8u master, the constructor is not correctly calling the super class,
now it is missing the PropertyMap parameter.
Since the patch was against jdk9, I wan't able to copy/paste it into my working
environment.
I hope this is my mistake, but I am sending just in case it affects others.
Currently:
jdk.nashorn.internal.objects.NativeFunction$Constructor();
Code: 0: aload_0 1: ldc #8 // String Function 3: ldc
#15 // MethodHandle invokestatic
jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction;
5: aconst_null 6: invokespecial #18 // Method
jdk/nashorn/internal/objects/ScriptFunctionImpl."<init>":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;[Ljdk/nashorn/internal/runtime/Specialization;)V
Previously it was: jdk.nashorn.internal.objects.NativeFunction$Constructor(); Code: 0:
aload_0 1: ldc #24 // String Function 3: ldc #31
// MethodHandle invokestatic
jdk/nashorn/internal/objects/NativeFunction.function:(ZLjava/lang/Object;[Ljava/lang/Object;)Ljdk/nashorn/internal/runtime/ScriptFunction;
5: getstatic #22 // Field $nasgenmap$:Ljdk/nashorn/internal/runtime/PropertyMap;
8: aconst_null 9: invokespecial #34 // Method
jdk/nashorn/internal/objects/ScriptFunctionImpl."<init>":(Ljava/lang/String;Ljava/lang/invoke/MethodHandle;Ljdk/nashorn/internal/runtime/PropertyMap;[Ljdk/nashorn/internal/runtime/Specialization;)V
Thanks,Ahmed
From: A. Sundararajan <sundararajan.athijegannat...@oracle.com>
To: nashorn-dev@openjdk.java.net
Sent: Thursday, June 18, 2015 2:57 PM
Subject: Re: RFR 8117883: nasgen prototype, instance member count calculation
is wrong
Hi,
Please review updated review
http://cr.openjdk.java.net/~sundar/8117883/webrev.01/
PS. Fixed for what Ahmed found in his previous email as well as cleanup
other things (like not adding CONSTRUCTOR, SPECIALIZED_FUNCTION
(constructor) as members for Constructor class) etc.
Thanks,
-Sundar
On Thursday 18 June 2015 11:57 AM, Ahmed Ashour wrote:
Hi Sundar,
PropertyGenerator is ok, but ConstructorGenerator still has the issue.
For example:
NativeArray:
static { ArrayList list = new ArrayList(7);
list.add(AccessorProperty.create("isArray", 2, "G$isArray", "S$isArray"));
$nasgenmap$ = PropertyMap.newMap(list); }
because ScriptClassInfo.getConstructorMemberCount() returns also
Kind.CONSTRUCTOR and .SPECIALIZED_FUNCTION, which are not 'added'.
Thanks a lot,Ahmed From: Ahmed Ashour <asash...@yahoo.com>
To: A. Sundararajan <sundararajan.athijegannat...@oracle.com>;
"nashorn-dev@openjdk.java.net" <nashorn-dev@openjdk.java.net>
Sent: Wednesday, June 17, 2015 9:41 PM
Subject: Re: RFR 8117883: nasgen prototype, instance member count
calculation is wrong
Hi Sundar,
Works great, thanks for the quick response.
I don't fully understand the removal of ScriptObject.isGenericDescriptor
I guess users are not allowed to be created in bugs.openjdk.java.net.
Thanks again,Ahmed
From: A. Sundararajan <sundararajan.athijegannat...@oracle.com>
To: "nashorn-dev@openjdk.java.net" <nashorn-dev@openjdk.java.net>
Sent: Wednesday, June 17, 2015 7:20 PM
Subject: RFR 8117883: nasgen prototype, instance member count calculation is
wrong
Please review http://cr.openjdk.java.net/~sundar/8117883/ for
https://bugs.openjdk.java.net/browse/JDK-8117883
Thanks,
-Sundar