Bug 1022 - GlueGen: Add support for compound [array] call-by-value (code generation)
Summary: GlueGen: Add support for compound [array] call-by-value (code generation)
Alias: None
Product: Gluegen
Classification: JogAmp
Component: core (show other bugs)
Version: 2
Hardware: All all
: --- enhancement
Assignee: Sven Gothel
Depends on:
Blocks: 1021 1025
  Show dependency treegraph
Reported: 2014-06-17 08:37 CEST by Sven Gothel
Modified: 2014-06-25 09:52 CEST (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
c3054a01990e55ab35756ea23ab7d7c05f24dd37 f4e753ff1f39be381307ffdb0fb6bb7a2d323eff 9843e983a4fc71a64eb3de9cb364a1f4ffa56b3a 1eadaf928f4f61aae4de1c8bf33c5b77bdfa882f 2f6586292cd298bbc19d8acda0f7cf303c82078b 6cb643671578aa912d16dd17e773d92f4667118b
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2014-06-17 08:37:17 CEST
For certain APIs we require support for inefficient call-by-value
of compounds and compound-arrays.

Both are inefficient, since:
  - compound array args need to copy data into c-heap
    and if non-const, even back to the NIO heap!

  - compound return values need to have new NIO heap
    allocated and data copied.

  - compound non-array args are not critical itself
Comment 1 Sven Gothel 2014-06-17 08:40:00 CEST
  GlueGen: Add support for 'compound call-by-value', i.e. passing and returning struct instance

  GlueGen: Add support for 'compound array call-by-value'

Tested manually w/ GlueGen unit tests
and validated JOAL, JOGL and JOCL builds and tests.

JOGL also does not expose API differences (of interfaces)
due to this change.
Comment 2 Sven Gothel 2014-06-17 23:07:05 CEST
  Fix commit f4e753ff1f39be381307ffdb0fb6bb7a2d323eff: 
    'compound array call-by-value' JavaMethodBindingEmitter, 
    array may still require NIO handling, also consider NIO arr
Comment 3 Sven Gothel 2014-06-18 01:45:43 CEST
Only add static initialization code (java, native)
and hence native code 'JVMUtil_NewDirectByteBufferCopy(..)'
if either required _or_ forced via configuration.

This shall reduce possible sideffects 
and dead code.

Add JavaConfiguration:

 * Returns true if the static initialization java code calling <code>initializeImpl()</code>
 * for the given class will be manually implemented by the end user
 * as requested via configuration directive <code>ManualStaticInitCall 'class-name'</code>.
public boolean manualStaticInitCall(String clazzName);

 * Returns true if the static initialization java code implementing <code>initializeImpl()</code>
 * and the native code implementing:
 * <pre>
 *   static jobject JVMUtil_NewDirectByteBufferCopy(JNIEnv *env, void * source_address, jlong capacity);
 * </pre>
 * for the given class will be included in the generated code, always,
 * as requested via configuration directive <code>ForceStaticInitCode 'class-name'</code>.
 * <p>
 * If case above code has been generated, static class initialization is generated
 * to call <code>initializeImpl()</code>, see {@link #manualStaticInitCall(String)}.
 * </p>
public boolean forceStaticInitCode(String clazzName);
Comment 4 Sven Gothel 2014-06-18 03:59:11 CEST
  - Changes as described in comment 3
  - JVMUtil_NewDirectByteBufferCopy: Throw FatalError if initializeImpl() has not been called
Comment 5 Sven Gothel 2014-06-19 06:14:02 CEST
    Add support for compound-array in structs (accessors) ; 
    Allow using C-Enum values for array length
  - Parser (HeaderParser.g): Support using C-Enum values 
    for array length specification
    - Will throw an exception if enum identifier is unknown or exceeds int-size
  - Add StructEmitter supports for compound-arrays
  - Add Debug stderr verbose info:
    - Struct Emitter prefix 'SE.' - to analyze 
      emitting struct fields (offset+size and accessors)

    - Struct Layout  prefix 'SL.' - to analyze 
      memory layout (based on MachineDescription.StaticConfig.X86_64_UNIX)
Tested via test1.[ch] BaseClass ..