[Java] Function binding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Java] Function binding

John Moeller
I promise that there will be some questions in here, but I wanted to
offer a bit of background first.

If I understand it correctly, the means of determining conversions of
function arguments from xxx functions to C++ functions is done through
the registry, probably in one of two scenarios:

1.  If a C++ argument type is known in advance (through a bound invoker,
for example), this argument type is a key in the registry to find the
correct conversion for the xxx type.
2.  If a C++ argument type is not known in advance (because of a need
for overload resolution), each overload should be attempted on-the-fly,
and as soon as an overload is found whose conversions all succeed, then
those converted values are used for the invoke() method of the invoker.

I have no problems with the above method; I'd surmise that it's
extremely useful (and possibly necessary) to use with a
dynamically-typed language.  However, for a statically-typed and
statically-declared language like Java, it doesn't really work.

The problem is that there needs to be a function for the Java class to
link to.  Since there isn't a way to generate a function dynamically
(other than to have a forwarding function with every possible argument
combination defined ahead of time; while possible up to a max arity, it
isn't feasible), that means that there needs to be a static (i.e.,
compile-time) way of creating a forwarding function that the Java class
may link to.  (By the way: varargs won't work; I investigated this
possibility, and it turns out that on Windows implementations of the Sun
JVM (and by extension, other JVM's), JNICALL is defined to be __stdcall.
  That means no varargs.)

The obvious way that I thought of to handle something like this was to
use fusion and/or mpl to create a (compile-time) transformed argument
list from a set of user-defined type associations.  Much like the user
defines a set of dynamic conversion functions for use with the invoker
class, a user could define a set of metafunctions that would define
legal conversions at compile time.  This would enable the transformed
argument list to be used to generate an instantiation of a function that
could be linked to a Java class.  This lazy list could then be used to
perform the actual conversions at runtime.

Another method I thought about was possibly something involving proto,
though I haven't really worked out a strategy there.

So here are my questions:

1.  Am I way off base, or did I miss something crucial in my assessment
of the situation?

2.  Being far more experienced metaprogrammers than myself, do you think
that a fusion/mpl (or possibly a proto) solution might work?  That is,
do you see any glaringly obvious problems with such a solution?

3.  Given that such a solution would essentially be a *replacement* of
the invocation architecture currently in place, which of the following
approaches would work best for Boost?

   a.  Make the solution generic enough to work with any binding, thus
having an alternative invocation architecture
   b.  Design a Java binding that would work independently of langbinding
   c.  Something else entirely

I'll also do more research into the design of what's already in place;
when I read through the posts in this group the first time, I didn't
understand what was going on as much as I do now.

Thanks for your time in reading this post.  I understand that there's a
lot going on right now.

--

John Moeller
[hidden email]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
John Moeller wrote:
> 3.  Given that such a solution would essentially be a *replacement* of
> the invocation architecture currently in place, which of the following
> approaches would work best for Boost?
>
>    a.  Make the solution generic enough to work with any binding, thus
> having an alternative invocation architecture

Let me stress here that I'm not suggesting removal of the existing
invocation architecture, just an addition to it.

Also, rereading some of the posts about the intent of langbinding, I
realize that what I suggest may not work for a
compile-once-link-anything kind of approach that langbinding tries to
achieve.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
In reply to this post by John Moeller
John Moeller wrote:

> So here are my questions:
>
> 1.  Am I way off base, or did I miss something crucial in my assessment
> of the situation?
>
> 2.  Being far more experienced metaprogrammers than myself, do you think
> that a fusion/mpl (or possibly a proto) solution might work?  That is,
> do you see any glaringly obvious problems with such a solution?
>
> 3.  Given that such a solution would essentially be a *replacement* of
> the invocation architecture currently in place, which of the following
> approaches would work best for Boost?
>
>    a.  Make the solution generic enough to work with any binding, thus
> having an alternative invocation architecture
>    b.  Design a Java binding that would work independently of langbinding
>    c.  Something else entirely
>
> I'll also do more research into the design of what's already in place;
> when I read through the posts in this group the first time, I didn't
> understand what was going on as much as I do now.

Hm, after going over the archives, it seems that there was originally an
initiative to have compile-time converter-generators, but this idea kind
of fell away in favor of on-demand argument conversion.

The compile-time approach or something similar is necessary to generate
the native functions for a Java class; the arguments of the native
function have to be declared -- that is, there isn't a "blob" of Java
arguments that can be parsed at runtime.  There are a couple of
alternatives that I've thought about, but they aren't very attractive
(at least to me).

When we can get around to discussing it, I'd like to discuss the idea of
maybe bringing the compile-time idea back.  In the meantime, I'll see
what I can do to sketch out something relating to the compile-time
approach on my own using fusion/mpl.

Thanks again for your attention.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

Rene Rivera-2
John Moeller wrote:
> The compile-time approach or something similar is necessary to generate
> the native functions for a Java class; the arguments of the native
> function have to be declared -- that is, there isn't a "blob" of Java
> arguments that can be parsed at runtime.  There are a couple of
> alternatives that I've thought about, but they aren't very attractive
> (at least to me).

I had a long offline conversation with John about bindings, for context
we worked together long ago to rewrite the Mac Common Lisp binding code,
and we came up with a portable way of doing the Java bindings. Briefly...

Langbinding provides a JNI class that manages in a generic way
forwarding calls back and forth between the Java and C++ sides. When
loading a C++ module, the Langbinding class reads the class descriptions
from the C++ module and generates in memory bytecode for the Java side
of those classes that just calls to the Lanbinding central class to
package calls and forward through the Langbinging class. The Langbinding
class loads the freshly generated bytecode classes into the JVM.

The drawback to this approach is the additional translation layer, but
perhaps this is a reasonable trade off given the extra flexibility
gained. Now if someone could figure out how to generate bytecode to
directly call C/C++ function pointers this extra layer could be removed.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
Rene Rivera wrote:

> John Moeller wrote:
>> The compile-time approach or something similar is necessary to generate
>> the native functions for a Java class; the arguments of the native
>> function have to be declared -- that is, there isn't a "blob" of Java
>> arguments that can be parsed at runtime.  There are a couple of
>> alternatives that I've thought about, but they aren't very attractive
>> (at least to me).
>
> I had a long offline conversation with John about bindings, for context
> we worked together long ago to rewrite the Mac Common Lisp binding code,
> and we came up with a portable way of doing the Java bindings. Briefly...

Out of curiosity, John who?  I know it's not me.  :)

> Langbinding provides a JNI class that manages in a generic way
> forwarding calls back and forth between the Java and C++ sides. When
> loading a C++ module, the Langbinding class reads the class descriptions
> from the C++ module and generates in memory bytecode for the Java side
> of those classes that just calls to the Lanbinding central class to
> package calls and forward through the Langbinging class. The Langbinding
> class loads the freshly generated bytecode classes into the JVM.

That's something that I hadn't thought about, but it's a cool idea.  How
would you package primitive arguments on the Java side?  Boxed, then
package them in an Object array, and unbox them on the native side?  Or
maybe package them in a class that had all the args?

> The drawback to this approach is the additional translation layer, but
> perhaps this is a reasonable trade off given the extra flexibility
> gained.

Honestly, I think that the common langbinding class is the best
approach, given the current invocation architecture.  You'd have a
common class like this anyway, even if you could generate your
forwarding functions at compile time, just to get the generated classes
loaded and linked to them.

At the very least, it's something that we could stumble through
creating.  Time for me to buy a couple books on bytecode.  Any suggestions?

> Now if someone could figure out how to generate bytecode to
> directly call C/C++ function pointers this extra layer could be removed.

Hm.  What function pointer would it call?  To have one with all the
arguments to match, you'd have to generate the function it points to at
compile time.  Or did I miss your meaning?

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

Rene Rivera-2
John Moeller wrote:

> Rene Rivera wrote:
>> John Moeller wrote:
>>> The compile-time approach or something similar is necessary to generate
>>> the native functions for a Java class; the arguments of the native
>>> function have to be declared -- that is, there isn't a "blob" of Java
>>> arguments that can be parsed at runtime.  There are a couple of
>>> alternatives that I've thought about, but they aren't very attractive
>>> (at least to me).
>> I had a long offline conversation with John about bindings, for context
>> we worked together long ago to rewrite the Mac Common Lisp binding code,
>> and we came up with a portable way of doing the Java bindings. Briefly...
>
> Out of curiosity, John who?  I know it's not me.  :)

That would be John Welch my business partner
<http://redshift-software.com/People.html>. He doesn't spend time in the
Boost lists, but that's likely to change soon.

>> Langbinding provides a JNI class that manages in a generic way
>> forwarding calls back and forth between the Java and C++ sides. When
>> loading a C++ module, the Langbinding class reads the class descriptions
>> from the C++ module and generates in memory bytecode for the Java side
>> of those classes that just calls to the Lanbinding central class to
>> package calls and forward through the Langbinging class. The Langbinding
>> class loads the freshly generated bytecode classes into the JVM.
>
> That's something that I hadn't thought about, but it's a cool idea.  How
> would you package primitive arguments on the Java side?

One item I'll mention a bit later is an abstraction of the C++ side of
things, currently I'm calling it a "meta-object binding" (to borrow a
bit from Lisp). You would package the call into a meta-object binding
that hold the args, what to call, and the result(s).

> Boxed, then
> package them in an Object array, and unbox them on the native side?  Or
> maybe package them in a class that had all the args?

The latter. The point would be to use an instance that matches the JNI
call in the Langbinding class.

> At the very least, it's something that we could stumble through
> creating.

Yea, I suspect they'll be a bit of stumbling for Java since AFAIK this
will be the first attempt in the Java world of doing something like this.

> Time for me to buy a couple books on bytecode.  Any suggestions?

Not immediately... I'll ask John as he has more Java experience in this
area. Note, the reason he knows this can work is because at one point he
was using a system that read in XSLT and generated equivalent bytecode
for doing the translations.

>> Now if someone could figure out how to generate bytecode to
>> directly call C/C++ function pointers this extra layer could be removed.
>
> Hm.  What function pointer would it call?  To have one with all the
> arguments to match, you'd have to generate the function it points to at
> compile time.  Or did I miss your meaning?

It's easy to generate the correct function signature, and even make it
callable from the C side. The AFAIK insurmountable part is that JNI
works *only* at a symbolic level. Not only must the function sig match,
the function symbol name *must* match the one proscribed by JNI. This is
likely a security limitation to make malicious native code injection
harder. But at the end it has to call through a plain function pointer.
Hence it's the symbolic function pointer lookup one would like to subvert.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
Rene Rivera wrote:
> John Moeller wrote:
>> Out of curiosity, John who?  I know it's not me.  :)
>
> That would be John Welch my business partner
> <http://redshift-software.com/People.html>. He doesn't spend time in the
> Boost lists, but that's likely to change soon.

Guess I'll be called by my whole name from now on.  :)

>>> Langbinding provides a JNI class that manages in a generic way
>>> forwarding calls back and forth between the Java and C++ sides. When
>>> loading a C++ module, the Langbinding class reads the class descriptions
>>> from the C++ module and generates in memory bytecode for the Java side
>>> of those classes that just calls to the Lanbinding central class to
>>> package calls and forward through the Langbinging class. The Langbinding
>>> class loads the freshly generated bytecode classes into the JVM.
>> That's something that I hadn't thought about, but it's a cool idea.  How
>> would you package primitive arguments on the Java side?
>
> One item I'll mention a bit later is an abstraction of the C++ side of
> things, currently I'm calling it a "meta-object binding" (to borrow a
> bit from Lisp). You would package the call into a meta-object binding
> that hold the args, what to call, and the result(s).
>
>> Boxed, then
>> package them in an Object array, and unbox them on the native side?  Or
>> maybe package them in a class that had all the args?
>
> The latter. The point would be to use an instance that matches the JNI
> call in the Langbinding class.

I get the idea of a function invocation package, but I don't follow what
you mean by "matches the JNI call".

Would you have a class that contained something like this:

{
   String functionName;
   String signature;
   Object args[];
}

And then dispatch to the invoker based on the function name?  Is that
what you mean?  Or do you mean something else?

>> At the very least, it's something that we could stumble through
>> creating.
>
> Yea, I suspect they'll be a bit of stumbling for Java since AFAIK this
> will be the first attempt in the Java world of doing something like this.
>
>> Time for me to buy a couple books on bytecode.  Any suggestions?
>
> Not immediately... I'll ask John as he has more Java experience in this
> area. Note, the reason he knows this can work is because at one point he
> was using a system that read in XSLT and generated equivalent bytecode
> for doing the translations.

Sweet.  :)

>>> Now if someone could figure out how to generate bytecode to
>>> directly call C/C++ function pointers this extra layer could be removed.
>> Hm.  What function pointer would it call?  To have one with all the
>> arguments to match, you'd have to generate the function it points to at
>> compile time.  Or did I miss your meaning?
>
> It's easy to generate the correct function signature, and even make it
> callable from the C side.

Ok, there's a difficulty there, namely, that there isn't a way in
langbinding (currently) to generate a function signature.  Say that you
had a C++ function that you wanted to wrap:

   int function(X *, double, bool);

You can't currently get this from langbinding:

   jint java_method(JNIEnv **, jobject, jdouble, jboolean);

because there isn't any static type information for the xxx side in the
converters, only a chain of from_xxx_functions registered with
registered<T_Cpp>.  That is, there's no way to back up from T_Cpp to
T_Java, because the most specific you can get is from_xxx_data, where
everything operates on void *.  This is fine if everything were wrapped
up in an invocation object like you described, but it doesn't suffice
for generating functions.

Unless of course, the function you're talking about is the one that
passes the invocation package.  If that's the case, nevermind.

> The AFAIK insurmountable part is that JNI
> works *only* at a symbolic level. Not only must the function sig match,
> the function symbol name *must* match the one proscribed by JNI. This is
> likely a security limitation to make malicious native code injection
> harder. But at the end it has to call through a plain function pointer.
> Hence it's the symbolic function pointer lookup one would like to subvert.

Huh?  You can call your native function anything you want if you use
RegisterNatives.  I exclusively use RegisterNatives now, because all that

   Java_com_domain_my_UberClass_destroyWorld__ILjava_lang_String2

nonsense gets old.  You would need at least one function declared this
way (the one that actually calls RegisterNatives), but it's unlikely to
change, and its signature is usually simple, so it makes it much more
manageable.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

David Abrahams
In reply to this post by John Moeller

on Sun Jun 24 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> I promise that there will be some questions in here, but I wanted to
> offer a bit of background first.
>
> If I understand it correctly, the means of determining conversions of
> function arguments from xxx functions to C++ functions is done through
> the registry, probably in one of two scenarios:
>
> 1.  If a C++ argument type is known in advance (through a bound invoker,
> for example), this argument type is a key in the registry to find the
> correct conversion for the xxx type.
> 2.  If a C++ argument type is not known in advance (because of a need
> for overload resolution), each overload should be attempted on-the-fly,
> and as soon as an overload is found whose conversions all succeed, then
> those converted values are used for the invoke() method of the invoker.

I don't think 1 and 2 have anything to do with one another.  They seem
to be on different axes.  I also don't know what you mean by "a bound
invoker."  The process is uniform whether there is one overload or N.

> I have no problems with the above method; I'd surmise that it's
> extremely useful (and possibly necessary) to use with a
> dynamically-typed language.  However, for a statically-typed and
> statically-declared language like Java, it doesn't really work.

Hm?

> The problem is that there needs to be a function

Java or C++ function?

> for the Java class to link to.

How did classes come into it?  I know everything in Java is a class,
but still...

What do you mean by "link?"

> Since there isn't a way to generate a function dynamically (other
> than to have a forwarding function with every possible argument
> combination defined ahead of time; while possible up to a max arity,
> it isn't feasible), that means that there needs to be a static
> (i.e., compile-time) way of creating a forwarding function that the
> Java class may link to.

If necessary, You can use the same backend interface that will be used
by the dynamic languages to generate C++ code that will be compiled in
a separate phase.  However it sounds like Rene has a slicker option.
I guess if Rene's approach is too slow, both options can be made
available.

> (By the way: varargs won't work; I investigated this possibility,
> and it turns out that on Windows implementations of the Sun JVM (and
> by extension, other JVM's), JNICALL is defined to be __stdcall.
> That means no varargs.)
>
> The obvious way that I thought of to handle something like this was
> to use fusion and/or mpl to create a (compile-time) transformed
> argument list from a set of user-defined type associations.  Much
> like the user defines a set of dynamic conversion functions for use
> with the invoker class, a user could define a set of metafunctions
> that would define legal conversions at compile time.  This would
> enable the transformed argument list to be used to generate an
> instantiation of a function that could be linked to a Java class.
> This lazy list could then be used to perform the actual conversions
> at runtime.

I'm not convinced the drawbacks would be worth the advantages.  For
one thing, it would bind the front-end at compile time to a particular
backend language, which we're trying to get away from.  If you can
make the front-end language-agnostic then you can properly focus
expertise.

Also I'm pretty sure that compilation would be slow for large
bindings.  Boost.Python already is slow for large bindings.  Using
more type erasure will speed that up dramatically.


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
David Abrahams wrote:

> on Sun Jun 24 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>
>> I promise that there will be some questions in here, but I wanted to
>> offer a bit of background first.
>>
>> If I understand it correctly, the means of determining conversions of
>> function arguments from xxx functions to C++ functions is done through
>> the registry, probably in one of two scenarios:
>>
>> 1.  If a C++ argument type is known in advance (through a bound invoker,
>> for example), this argument type is a key in the registry to find the
>> correct conversion for the xxx type.
>> 2.  If a C++ argument type is not known in advance (because of a need
>> for overload resolution), each overload should be attempted on-the-fly,
>> and as soon as an overload is found whose conversions all succeed, then
>> those converted values are used for the invoke() method of the invoker.
>
> I don't think 1 and 2 have anything to do with one another.  They seem
> to be on different axes.  I also don't know what you mean by "a bound
> invoker."  The process is uniform whether there is one overload or N.

By a "bound invoker," I mean a langbinding::function::invoker object
that could be tied directly to a xxx function call.  I realized later
that that's basically an impossibility without static converter chains.

>> I have no problems with the above method; I'd surmise that it's
>> extremely useful (and possibly necessary) to use with a
>> dynamically-typed language.  However, for a statically-typed and
>> statically-declared language like Java, it doesn't really work.
>
> Hm?
>
>> The problem is that there needs to be a function
>
> Java or C++ function?
>
>> for the Java class to link to.
>
> How did classes come into it?  I know everything in Java is a class,
> but still...
>
> What do you mean by "link?"

The normal way of implementing native bindings with JNI is to expose a
function from your native library that has a signature that corresponds
to the signature of the Java native method being bound.

This is an impossibility (rather, impractical to the point of
impossibility) without compile-time conversion, but as you point out
below, Rene has a novel solution to this problem.  Shunting everything
through an interface that passes packaged function calls eliminates the
need for compile-time function generation.

>> Since there isn't a way to generate a function dynamically (other
>> than to have a forwarding function with every possible argument
>> combination defined ahead of time; while possible up to a max arity,
>> it isn't feasible), that means that there needs to be a static
>> (i.e., compile-time) way of creating a forwarding function that the
>> Java class may link to.
>
> If necessary, You can use the same backend interface that will be used
> by the dynamic languages to generate C++ code that will be compiled in
> a separate phase.  However it sounds like Rene has a slicker option.
> I guess if Rene's approach is too slow, both options can be made
> available.

That's an approach I thought of as well, but I was hoping to avoid it.
I like Rene's approach better; though it could have some overhead.  What
I worry about is the "unboxing" of primitive arguments (int, double,
etc.).  It's generally an unnoticable overhead (if any) to call a native
function, but it can get hefty to go in reverse.

>> (By the way: varargs won't work; I investigated this possibility,
>> and it turns out that on Windows implementations of the Sun JVM (and
>> by extension, other JVM's), JNICALL is defined to be __stdcall.
>> That means no varargs.)
>>
>> The obvious way that I thought of to handle something like this was
>> to use fusion and/or mpl to create a (compile-time) transformed
>> argument list from a set of user-defined type associations.  Much
>> like the user defines a set of dynamic conversion functions for use
>> with the invoker class, a user could define a set of metafunctions
>> that would define legal conversions at compile time.  This would
>> enable the transformed argument list to be used to generate an
>> instantiation of a function that could be linked to a Java class.
>> This lazy list could then be used to perform the actual conversions
>> at runtime.
>
> I'm not convinced the drawbacks would be worth the advantages.  For
> one thing, it would bind the front-end at compile time to a particular
> backend language, which we're trying to get away from.  If you can
> make the front-end language-agnostic then you can properly focus
> expertise.

That makes a lot of sense.

> Also I'm pretty sure that compilation would be slow for large
> bindings.  Boost.Python already is slow for large bindings.  Using
> more type erasure will speed that up dramatically.

Yeah, I suppose it's a tradeoff.  Development cycles can get frustrating
with long build times.

I appreciate the explanations.  That clears a lot up for me.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

David Abrahams

on Tue Jul 03 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

>>> The problem is that there needs to be a function
>>
>> Java or C++ function?
>>
>>> for the Java class to link to.
>>
>> How did classes come into it?  I know everything in Java is a class,
>> but still...
>>
>> What do you mean by "link?"
>
> The normal way of implementing native bindings with JNI is to expose a
> function from your native library that has a signature that corresponds
> to the signature of the Java native method being bound.

Yep, I know.

<snip>

>>> Since there isn't a way to generate a function dynamically (other
>>> than to have a forwarding function with every possible argument
>>> combination defined ahead of time; while possible up to a max
>>> arity, it isn't feasible), that means that there needs to be a
>>> static (i.e., compile-time) way of creating a forwarding function
>>> that the Java class may link to.
>>
>> If necessary, You can use the same backend interface that will be used
>> by the dynamic languages to generate C++ code that will be compiled in
>> a separate phase.  However it sounds like Rene has a slicker option.
>> I guess if Rene's approach is too slow, both options can be made
>> available.
>
> That's an approach I thought of as well, but I was hoping to avoid it.
> I like Rene's approach better; though it could have some overhead.  What
> I worry about is the "unboxing" of primitive arguments (int, double,
> etc.).  It's generally an unnoticable overhead (if any) to call a native
> function, but it can get hefty to go in reverse.

You know lots more about the Java issues than I do... but wouldn't
that issue of going in reverse apply no matter what technique we use?

>> I'm not convinced the drawbacks would be worth the advantages.  For
>> one thing, it would bind the front-end at compile time to a particular
>> backend language, which we're trying to get away from.  If you can
>> make the front-end language-agnostic then you can properly focus
>> expertise.
>
> That makes a lot of sense.
>
>> Also I'm pretty sure that compilation would be slow for large
>> bindings.  Boost.Python already is slow for large bindings.  Using
>> more type erasure will speed that up dramatically.
>
> Yeah, I suppose it's a tradeoff.  Development cycles can get frustrating
> with long build times.
>
> I appreciate the explanations.  That clears a lot up for me.

I'm glad I could help.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function binding

John Moeller
David Abrahams wrote:

> on Tue Jul 03 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>>> If necessary, You can use the same backend interface that will be used
>>> by the dynamic languages to generate C++ code that will be compiled in
>>> a separate phase.  However it sounds like Rene has a slicker option.
>>> I guess if Rene's approach is too slow, both options can be made
>>> available.
>> That's an approach I thought of as well, but I was hoping to avoid it.
>> I like Rene's approach better; though it could have some overhead.  What
>> I worry about is the "unboxing" of primitive arguments (int, double,
>> etc.).  It's generally an unnoticable overhead (if any) to call a native
>> function, but it can get hefty to go in reverse.
>
> You know lots more about the Java issues than I do... but wouldn't
> that issue of going in reverse apply no matter what technique we use?

In the case where you generate code for C++, you could create direct
bindings for the Java native methods.  Which means that it's possible to
design an interface that only calls from Java.

I'm also getting ahead of myself.  I'd really need to measure before I
could say for sure that there would be a performance hit.  The classic
wisdom is that making JVM calls is slower than making native calls, but
that wisdom was born years ago, and a lot has changed since then.

Regardless, I'll make sure that we have a proper apples-to-apples test
against a "normal" use of calls across the JNI boundary.  My colleagues
at work occasionally refer to "the cost of a native call," which makes
me bristle.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding