Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
ExaHyPE-Engine
ExaHyPE-Engine
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 68
    • Issues 68
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

11.3.2021, 9:00 - 11:00: Due to updates GitLab may be unavailable for some minutes between 09:00 and 11:00.

  • ExaHyPE
  • ExaHyPE-EngineExaHyPE-Engine
  • Issues
  • #237

Closed
Open
Opened Aug 04, 2018 by Dominic Etienne Charrier@domchaOwner

Toolkit extensibility threatened by java method size limit

Problem description

When adding a few more tokens to the exahype.grammar file, the ExaHyPE Toolkit does not compile anymore. The compilation stops with the following error:

javac -cp ../lib/commons-cli.jar -sourcepath . eu/exahype/GenerateSolverRegistration.java  
eu/exahype/parser/Parser.java:104: error: code too large
    public Start parse() throws ParserException, LexerException, IOException
                 ^
1 error

Function parse() in file eu/exahype/parser/Parser.java contains a large switch-case statement considering nearly 3000 cases and has more than 17000 lines of code. Parser.java is unfortunately autogenerated by SableCC.

Further reading:

  • https://dzone.com/articles/method-size-limit-java
  • https://stackoverflow.com/a/17422590

The Typical Let's rewrite everything! Proposal

From my point of view, above issue is just another reason why we should abandon SableCC grammars and switch to a proper data serialisation format like JSON or YAML (internally). Validation can be performed via JSON schemata. It would be still possible to keep our current specification file format. We would just introduce a precompilation step.

Additionally, we could consider to rewrite the toolkit in python. A lot is realised via template files anyway and the code generator for the optimised kernels is written in python, too.

Edited Aug 04, 2018 by Dominic Etienne Charrier
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: exahype/ExaHyPE-Engine#237