Re: [classlib] mem
(sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. My 2c. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] mem
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 12:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] mem (sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. What's the downside of renaming? There is no required relationship between the two... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Magnusson, Geir wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 12:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] mem (sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. What's the downside of renaming? There is no required relationship between the two... It is simple to find the function once you know that they have the same name. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote: Tim Ellison wrote: This function is (deliberately) not exported from the hyprt.dll so you cannot call it directly. You have to call it via the function pointer table ... That's the missing element - it's not exported. The idea is that code should always go via the function table so that your caller can control your use of these functions. Of course, you can reference that member directly if you so choose, and as written elsewhere if you are dealing with multiple tables the syntactic sugar doesn't help and you must reference it in full. When would you have multiple tables? Very rarely (Jimmy brought it up, so maybe he has an example). It would be more common to modify the table before you pass it on, to include a function that has more debug info (like the callsite version we saw earlier), or allocates from a given memory pool, or limits the amount of resource you can have, runs on a certain processor, etc. etc. I guess that the confusion is caused by the HyPortLib struct containing a member called 'mem_allocate_memory' that has the address of a function called 'hymem_allocate_memory'? really it was having a macro and a function named the same, differing only by a number of arguments where the macro expanded out to what has the potential of being something very different than the function because of the function table. It wasn't obvious that the function wasn't exported (of course). Right. As you see, the macro names follow a convention that matches the default table value function name -- once you are comfortable with that programming using the macros is not much different to programming direct to the function itself (modulo first portlib arg). Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: This function is (deliberately) not exported from the hyprt.dll so you cannot call it directly. You have to call it via the function pointer table ... That's the missing element - it's not exported. The idea is that code should always go via the function table so that your caller can control your use of these functions. Yes - exactly. That makes perfect sense to me. Of course, you can reference that member directly if you so choose, and as written elsewhere if you are dealing with multiple tables the syntactic sugar doesn't help and you must reference it in full. When would you have multiple tables? Very rarely (Jimmy brought it up, so maybe he has an example). It would be more common to modify the table before you pass it on, to include a function that has more debug info (like the callsite version we saw earlier), or allocates from a given memory pool, or limits the amount of resource you can have, runs on a certain processor, etc. etc. I guess that the confusion is caused by the HyPortLib struct containing a member called 'mem_allocate_memory' that has the address of a function called 'hymem_allocate_memory'? really it was having a macro and a function named the same, differing only by a number of arguments where the macro expanded out to what has the potential of being something very different than the function because of the function table. It wasn't obvious that the function wasn't exported (of course). Right. As you see, the macro names follow a convention that matches the default table value function name -- once you are comfortable with that programming using the macros is not much different to programming direct to the function itself (modulo first portlib arg). I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime
before we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
Yes, they are same in general case. And I think the hymem__xxx
usage is prefered, because they are more handy and they encapsulate the
HyPortLibrary's structure.
However, sometimes the two usage maybe different, it is possible to
create multiple HyPortLibrary instance within one VM instance, and the
developer can specify which HyPortLibrary instance he wants to use by
explicitly invoke portLib-blabla.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I think the second style is more readable, so would advocate using that.
As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
directives, so that you can use them if you are passed different types.
PORT_ACCESS_FROM_ENV(JNIEnv) - you have a JNIEnv struct ptr
PORT_ACCESS_FROM_JAVAVM(JavaVM) - you have a JavaVM struct ptr
PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Tim Ellison wrote:
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I think the second style is more readable, so would advocate using that.
As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
directives, so that you can use them if you are passed different types.
PORT_ACCESS_FROM_ENV(JNIEnv) - you have a JNIEnv struct ptr
PORT_ACCESS_FROM_JAVAVM(JavaVM) - you have a JavaVM struct ptr
PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
So in the scenario of multiple HyPortLib instances, it can be used to
specify which one to use? Then how about document these directives and
advocation on the port documentation instead of current ones?
Regards,
Tim
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Paulex Yang wrote: Tim Ellison wrote: snip PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr So in the scenario of multiple HyPortLib instances, it can be used to specify which one to use? You are right, when you have multiple instances the simple macros do not help and you need to revert to - . Then how about document these directives and advocation on the port documentation instead of current ones? Thanks for volunteering ;-) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)?
Well, the one I'm looking at is
hymem.c
void *VMCALL
hymem_allocate_memory (struct HyPortLibrary *portLibrary,
UDATA byteAmount)
If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I've heard this rumor before, but I don't ever see how.
PORT_ACCESS_FROM_* is a simple little macro that just returns *portLib.
geir
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Tim Ellison wrote:
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I think the second style is more readable, so would advocate using that.
As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
directives, so that you can use them if you are passed different types.
PORT_ACCESS_FROM_ENV(JNIEnv) - you have a JNIEnv struct ptr
PORT_ACCESS_FROM_JAVAVM(JavaVM) - you have a JavaVM struct ptr
PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
Except...
1) They aren't as Jimmy suggests, at least the one's I'm looking at.
2) the implementation in hymem.c just calls malloc()
I'm confused.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)?
Well, the one I'm looking at is
hymem.c
void *VMCALL
hymem_allocate_memory (struct HyPortLibrary *portLibrary,
UDATA byteAmount)
If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I've heard this rumor before, but I don't ever see how.
PORT_ACCESS_FROM_* is a simple little macro that just returns *portLib.
yeah, that's right - the PORT_ACCESS_FROM_* macro (defined
in hyport.h) sets the pointer privatePortLibrary to address the relevant
port library.
Also defined in hyport.h is hymem_allocate_memory(param1) (the single param
function Jimmy was talking about) which is a macro defined to be:
privatePortLibrary-mem_allocate_memory(privatePortLibrary, param1).
So the call to PORT_ACCESS_FROM_* sets up a port library pointer, and the
macro versions of the hymem calls automatically add it in as the first
parameter
to the relevant function call.
Regards,
Oliver
geir
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Jimmy, Jing Lv wrote:
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
I think the second style is more readable, so would advocate using that.
As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
directives, so that you can use them if you are passed different types.
PORT_ACCESS_FROM_ENV(JNIEnv) - you have a JNIEnv struct ptr
PORT_ACCESS_FROM_JAVAVM(JavaVM) - you have a JavaVM struct ptr
PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
Except...
1) They aren't as Jimmy suggests, at least the one's I'm looking at.
2) the implementation in hymem.c just calls malloc()
I'm confused.
Hopefully you are no longer confused after Oliver's explanation.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Oliver Deakin wrote: Also defined in hyport.h is hymem_allocate_memory(param1) (the single param function Jimmy was talking about) which is a macro defined to be: privatePortLibrary-mem_allocate_memory(privatePortLibrary, param1). Ah. Thanks. I didn't see that. I'll continue answering tim's followup. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Tim Ellison wrote: Geir Magnusson Jr wrote: Except... 1) They aren't as Jimmy suggests, at least the one's I'm looking at. 2) the implementation in hymem.c just calls malloc() I'm confused. Hopefully you are no longer confused after Oliver's explanation. Yes, although I am still confused why you would want to do this. We have an implementation in hymem.c : hymem_alloc_memory( HyPortLib *, int ) which looks just like hymem_alloc_memory(int) (if you use the right header) and it calls what might be two radically different things. Why do we have himem.c? Should we rename? Toss? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Except... 1) They aren't as Jimmy suggests, at least the one's I'm looking at. 2) the implementation in hymem.c just calls malloc() I'm confused. Hopefully you are no longer confused after Oliver's explanation. Yes, although I am still confused why you would want to do this. (I hope I see what you are confused about, but correct me if I'm wrong) We have an implementation in hymem.c : hymem_alloc_memory( HyPortLib *, int ) That is the actual function that allocates memory, and in this case it is platform specific, eventually calling HeapAlloc on Windows and malloc on Linux. This function is (deliberately) not exported from the hyprt.dll so you cannot call it directly. You have to call it via the function pointer table ... sidebarThere is also a similar function called hymem_allocate_memory_callSite that has an extra param to help debug the memory allocation calling site)/sidebar which looks just like hymem_alloc_memory(int) (if you use the right header) This is a macro defined in portlib.h that adds syntactic sugar so you can write hymem_alloc_memory(int) and the compiler will expand it into the function table look-up for you. ... #define hymem_allocate_memory(param1) privatePortLibrary-mem_allocate_memory(privatePortLibrary,param1) ... where 'privatePortLibrary' was obtained most likely from a JNIEnv struct or a JavaVM struct etc. and 'mem_allocate_memory' is the member in the function table (as defined in hyport.h) that contains the address of the function 'hymem_allocate_memory()' described above. See the definition, in portpriv.h, for static HyPortLibrary MasterPortLibraryTable = ... Of course, you can reference that member directly if you so choose, and as written elsewhere if you are dealing with multiple tables the syntactic sugar doesn't help and you must reference it in full. sidebarJust noticed that the hyport.h contains this directive #undef hymem_allocate_memory #define hymem_allocate_memory(param1) \ privatePortLibrary- \ mem_allocate_memory_callSite(privatePortLibrary,param1, \ HY_GET_CALLSITE()) so we are actually using the _callSite slot each time./sidebar and it calls what might be two radically different things. You lost me here ... The macro always expands out to a reference like this: privatePortLibrary (local var, defined by PORTLIB... macro) - mem_allocate_memory (address of function hymem_allocate_memory) (privatePortLibrary,param1) (invocation) I guess that the confusion is caused by the HyPortLib struct containing a member called 'mem_allocate_memory' that has the address of a function called 'hymem_allocate_memory'? Why do we have himem.c? Should we rename? Toss? (assuming himem.c == hymem.c) Do you mean rename the file / function / struct member / macro or all of the above ;-) ? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Except... 1) They aren't as Jimmy suggests, at least the one's I'm looking at. 2) the implementation in hymem.c just calls malloc() I'm confused. Hopefully you are no longer confused after Oliver's explanation. Yes, although I am still confused why you would want to do this. (I hope I see what you are confused about, but correct me if I'm wrong) We have an implementation in hymem.c : hymem_alloc_memory( HyPortLib *, int ) That is the actual function that allocates memory, and in this case it is platform specific, eventually calling HeapAlloc on Windows and malloc on Linux. This function is (deliberately) not exported from the hyprt.dll so you cannot call it directly. You have to call it via the function pointer table ... That's the missing element - it's not exported. [snip obvious stuff] Of course, you can reference that member directly if you so choose, and as written elsewhere if you are dealing with multiple tables the syntactic sugar doesn't help and you must reference it in full. When would you have multiple tables? [snip] I guess that the confusion is caused by the HyPortLib struct containing a member called 'mem_allocate_memory' that has the address of a function called 'hymem_allocate_memory'? really it was having a macro and a function named the same, differing only by a number of arguments where the macro expanded out to what has the potential of being something very different than the function because of the function table. It wasn't obvious that the function wasn't exported (of course). thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] mem
Why would I use portLib-mem_allocate_memory(portLib) over just calling hymem_allocate_memory(portlib, ) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
