Repository navigation
Fix SPARK-1609: Executor fails to start when Command.extraJavaOptions contains multiple Java options - #547
Closed
witgo wants to merge 9 commits into
Closed
Fix SPARK-1609: Executor fails to start when Command.extraJavaOptions contains multiple Java options#547witgo wants to merge 9 commits into
witgo wants to merge 9 commits into
Conversation
|
Can one of the admins verify this patch? |
Contributor
There was a problem hiding this comment.
Use Utils.splitCommandString instead of this, in case people pass in stuff with quotes.
Contributor
There was a problem hiding this comment.
Up to you, but could be written a bit more consicely
val extraOpts = command.extraJavaOptions.map(Utils.splitCommandString).getOrElse(Seq())
Contributor
Author
There was a problem hiding this comment.
Yes, val extraOpts = command.extraJavaOptions.map(Utils.splitCommandString).getOrElse(Seq()) is better
Contributor
|
Jenkins, test this please. |
|
Merged build triggered. |
|
Merged build started. |
|
Merged build finished. All automated tests passed. |
|
All automated tests passed. |
Contributor
|
Thanks for the fix! I've merged this |
asfgit
pushed a commit
that referenced
this pull request
Apr 28, 2014
… contains multiple Java options Author: witgo <witgo@qq.com> Closes #547 from witgo/SPARK-1609 and squashes the following commits: deb6a4c [witgo] review commit 91da0bb [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 0640852 [witgo] review commit 8f90b22 [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 bcf36cb [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 1185605 [witgo] fix extraJavaOptions split f7c0ab7 [witgo] bugfix 86fc4bb [witgo] bugfix 8a265b7 [witgo] Fix SPARK-1609: Executor fails to start when use spark-submit
pdeyhim
pushed a commit
to pdeyhim/spark-1
that referenced
this pull request
Jun 25, 2014
… contains multiple Java options Author: witgo <witgo@qq.com> Closes apache#547 from witgo/SPARK-1609 and squashes the following commits: deb6a4c [witgo] review commit 91da0bb [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 0640852 [witgo] review commit 8f90b22 [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 bcf36cb [witgo] Merge branch 'master' of https://github.com/apache/spark into SPARK-1609 1185605 [witgo] fix extraJavaOptions split f7c0ab7 [witgo] bugfix 86fc4bb [witgo] bugfix 8a265b7 [witgo] Fix SPARK-1609: Executor fails to start when use spark-submit
helenyugithub
pushed a commit
to helenyugithub/spark
that referenced
this pull request
Aug 20, 2019
Upgrade hadoop to new version.
MaxGekk
added a commit
to MaxGekk/spark
that referenced
this pull request
Oct 2, 2026
### What changes were proposed in this pull request? Thirteen open rows of milestone 6 move to milestone 7, on the owner's decision of 2 October 2026 after the review of the milestone's open rows before its close. Each was read against the milestone's done-when list (`PLAN_MILESTONE_6.md` 1.3) and against the size-control rows, the goal set on 30 September, and none bears on either: - **180**, promotion, continuously: a cadence (the cross-posts, a findings post every two weeks, a living benchmark page) rather than a task the milestone could close; carried, as decided on 1 October. - **182**, extending Spark's own benchmarks: it was milestone 7's item 8, and returns to it. - **207 and 208**, two measured micro-optimisations of the range-set kernel. - **213**, the warm-up choosing which drivers to compile from statistics. - **214 to 217 and 224**, the rest of the Java port - the time, condition and chrono families, the facade, and the benchmark harness adapter with `VarkaEmitDump` - mechanical, and meant for an agent. - **218**, optional research into why the loop predicate cycles. - **222**, structural hashing of IR nodes, a compile-time cost. - **231**, the fallback path's row loops reading columns through the batch's vectors. The moves follow the precedent of 15 and 21 September (milestone 5's rows into items 15 and 39): every row keeps its text and number in `PLAN_MILESTONE_6.md` with a "Moved to milestone 7" note at its head, so every citation still resolves; sections 2.8 and 2.9, the design sections of 182 and 180, carry a note under their headings; section 8 lists the thirteen; and `SCOPE_MILESTONE_7.md` item 81 tables them with where each design is and why each left. Row 181, the second post, published on 1 October, is marked done, the way row 210 was for the first. What is left open in milestone 6 after this and the pull requests in flight (apache#544 closing 233, apache#546 closing 235, apache#547 closing 223 and adding 239): the two size-control rows, 236 (plan a kernel's size before building it) and 239 (locals a loop method stores and never reads). ### Why are the changes needed? So that milestone 6 can close on what it set out to do, and the moved work keeps its place and its reasons. ### Does this PR introduce _any_ user-facing change? No. Two planning documents. ### How was this patch tested? `dev/varka_quote_check.py` reports zero orphans and `dev/varka_precommit.sh` no findings. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5.5)
MaxGekk
pushed a commit
to MaxGekk/spark
that referenced
this pull request
Oct 2, 2026
A code review of apache#547 found the per-body count following edges the walk does not: a calendar node's edge to a date whose materialized prefix the body loads without visiting it, and one edge per calendar node where a shared prefix visits its date once per fragment, which together left 5,722 shared slots nothing read over the cost corpus. Slots.bodyUses now asks the emission's own rule: a date edge counts once per prefix fragment's key and not at all where the prefix is loaded and the date not visited (Slots.visitsLoadedDate, which emitChronoPrefixOnce asks too). The fragment key's word is now the word's owner in the kernel's word algebra, or a marker for a dead word, so the key is known before any slot is numbered and tells words apart as their slots do. The suite the plan promised, VarkaUnreadLocalsSuite, holds every loop and epilogue method of the cost corpus to no unread shared slot; building it found a third such edge, an IsNotNull's edge to its column, whose word it reads but never its vector. No method of the corpus grows and 2,692 shrink. Also from the review: the count runs only for a loop or epilogue body under CSE; Analysis.useCount, whose counts nothing read, is the set it had become; section 7 of the plan said a count too low loads an unset local, where it recomputes the node. The emitted-bytes oracle, the price tables and the cost audit are regenerated, and VarkaEmitterBudgetSuite's shared HugeMethodLimit crossings move later, 49 to 51 with the bitmap pass and 44 to 45 without, since a date no longer keeps a slot the shared prefix reads once. PLAN_TASK_223.md 9.4 records the nine findings and their answers. Generated-by: Claude Code (Claude Opus 5.5)
MaxGekk
pushed a commit
to MaxGekk/spark
that referenced
this pull request
Oct 2, 2026
Task 223's review (apache#547) removed the 5,722 shared slots nothing read, so the plan's census, taken again on its head, finds 116,266 reference locals stored and never read - the segments, the reloads and the masks, unchanged - and trimming them takes 3.34% off the loop and epilogue bytes. Section 3.5 no longer leaves the shared slots named: VarkaUnreadLocalsSuite, which that review added for shared slots, is the check this task widens to every kind, with no kind left to name. Row 239 says the same. Generated-by: Claude Code (Claude Opus 5.5)
MaxGekk
added a commit
to MaxGekk/spark
that referenced
this pull request
Oct 2, 2026
### What changes were proposed in this pull request? `VarkaEmitCostAuditSuite` fails on master. apache#552 regenerated `sql/varka/emit_cost_audit.json` before apache#547 merged, and apache#547's review changed what the emitter builds. Its use count follows the walk's rule and leaves fewer dead slots, which removes enough bytes from long composition 5 of the audit's wide compositions that its one byte regroup with the prediction off no longer fires. The two PRs merged textually, so master's file still has the old count. This regenerates the file on master: one count moves from 1 to 0, and that shape's rebuild list loses the regroup. `PLAN_TASK_236.md` 2.1 notes that the shapes rebuilt on bytes went from 2 to 1; every other figure there stands. ### Why are the changes needed? Master's own suite fails without it, and so would every Varka PR's CI. ### Does this PR introduce _any_ user-facing change? No. A regenerated test oracle and a note in a plan. ### How was this patch tested? `VarkaEmitCostAuditSuite` passes against the regenerated file on master; `dev/varka_quote_check.py` reports zero orphans. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5.5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.