Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch RDD bindings to using inline-java under the hood. #103

Merged
merged 2 commits into from
Apr 11, 2017

Conversation

mboes
Copy link
Member

@mboes mboes commented Apr 9, 2017

Using inline-java slows down the compilation of sparkle, but is safer
because we can thus get the benefit of both type checkers (Java and
Haskell). In fact the extra safety isn't just theoretical: this patch
also includes a fix to the binding for treeAggregate, which was
supplying arguments in the wrong order.

This is preliminary work ahead of implementing #57, which we can do
serenely from the moment that the type checkers have our back.

This patch only switches over RDD for now. The rest can come later.

mboes added 2 commits April 9, 2017 17:34
Using inline-java slows down the compilation of sparkle, but is safer
because we can thus get the benefit of *both* type checkers (Java and
Haskell). In fact the extra safety isn't just theoretical: this patch
also includes a fix to the binding for `treeAggregate`, which was
supplying arguments in the wrong order.

This is preliminary work ahead of implementing #57, which we can do
serenely from the moment that the type checkers have our back.

This patch only switches over RDD for now. The rest can come later.
@facundominguez
Copy link
Member

This is not easy to have working on multinode setups unless inline-java is updated. For one of our projects we addressed this by not embedding generated bytecode in executables. Will submit the PR for this as soon as I can.

@mboes
Copy link
Member Author

mboes commented Apr 9, 2017

This is not easy to have working on multinode setups unless inline-java is updated. For one of our projects we addressed this by not embedding generated bytecode in executables.

Could you clarify what the issue is? Embedding the bytecode simplifies packaging/deployment quite a bit, and helps with modularity, so I'd be loath to abandon it. Note that the bindings don't require anonymous classes, even if user code might.

@facundominguez
Copy link
Member

facundominguez commented Apr 9, 2017

When a executor receives a serialized object, it needs to load the class before decoding the object is possible. As only the driver executes loadJavaWrappers, how does the executor load the classes in the embedded bytecode?

@facundominguez
Copy link
Member

facundominguez commented Apr 10, 2017

On second check, none of the code introduced in this PR seems to be sending to the executors objects of classes defined with inline-java. So the problem I was discussing does not affect usage in this case, as you well noted. Excuse me for the noise.

@mboes
Copy link
Member Author

mboes commented Apr 10, 2017

Right. I'd still be keen to see a ticket describing the issue you mention about inline-java in the general case though.

@mboes mboes requested a review from alpmestan April 10, 2017 16:47
Copy link
Contributor

@alpmestan alpmestan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure whether you accidentally assigned me for a review here or not, but LGTM.

@mboes
Copy link
Member Author

mboes commented Apr 10, 2017

@alpmestan Heh, surely not. ;) You're the author of most of the original bindings in this module, so Github rightly suggested to give you a shout.

@mboes mboes merged commit 963a691 into master Apr 11, 2017
@mboes mboes deleted the use-inline-java-rdd branch April 11, 2017 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants