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

Replace Javassist with ASM #636

Open
dzikoysk opened this issue Apr 2, 2021 · 13 comments
Open

Replace Javassist with ASM #636

dzikoysk opened this issue Apr 2, 2021 · 13 comments

Comments

@dzikoysk
Copy link
Member

dzikoysk commented Apr 2, 2021

No description provided.

@8BitAurum
Copy link

Hi! Sorry to bother you. Are you trying to use ASM instead of Javassist for performance reasons? [ASM is lower level than Javassist (which still uses ASM under the hood anyway) ]

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 3, 2021

Hi, well, ASM library is just smaller (should be like 200kb instead of 750kb) and doesn't have to compile string based java-like code to generate classes, so it may improve the parse time. Also, the Javassist 3.x is not based on asm library.

@8BitAurum
Copy link

Yeah. ASM is more lightweight, powerful and is considered the industry standard, being used to build languages like Kotlin, Scala, Panda 😉 etc.

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 4, 2021

Kinda, but it requires from user precisely defined target, so it is not as good as javassist to prototype some behaviours. I'm still trying to figure it out how to properly find a balance between generated bytecode and abstraction of this interpreted language 😳

@8BitAurum
Copy link

8BitAurum commented Apr 5, 2021

Have you tried desugaring your Panda program? This means you can have all the abstractions you want and the interpreter can handle generating bytecode from the desugared syntax.

EDIT: Desugaring basically means you remove all abstractions and make your language easier to compile/interpret/generate Bytecode etc.

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 5, 2021

It's not this kind of problem. If I'd like to generate full bytecode for whole app, I could just do that and forget about the problem. It's more about overall design and the way how language works in situations like Java interop, preserving the abstraction for further feature expansion. I'm still not decided in this field and it's why it also irritates me 😶

@8BitAurum
Copy link

If you are going with Java interop, what is your main focus? To call Java libraries/API into panda? Or, do you want to call Panda files from Java?

The former is relatively easy, the latter though, you have make sure your bytecode is on point. If you want both, that is, completely smooth interoperability between Java and Panda, it helps to take a look at other languages that have already implemented this ( ex. Kotlin ) for inspiration.

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 8, 2021

Yeah, I'm pretty sure that I'm the problem in this case due to my indecision. At this moment I don't want to maintain bidirectional support, so the most important thing is to provide smooth backend for Panda to access all of the Java sources. It's something what already works, but the implemention is such a mess because of the legacy and various concepts in the past.

@8BitAurum
Copy link

Then, in this case, all you need is a small cleanup. Can’t wait to see the result! 😝

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 8, 2021

Yeah, me too. It's probably why the development process is such a fun to write with all these different ideas. It's not only just reproducing another language, but it's all about experiencing a new "world" if I can say that. It's hard to disagree if I tell you that in indev phase, parsers where handled by builtin dependency injection api with runtime code generation of callbacks to improve the performance of interpretation xD

@8BitAurum
Copy link

8BitAurum commented Apr 9, 2021

parsers where handled by builtin dependency injection api with runtime code generation of callbacks to improve the performance of interpretation xD

O_O That's a lot to take in.

Then again, about the "referencing Java API" bit, are you going for a reflection based referencing or are you implement something like an import system?

  • Reflection can help in easy loading of Java libraries but it will come at the cost of compile time (interpretation time in your case)
  • An import system, on the other hand, makes for easy interpretation but will throw an error if the user misses an import.

EDIT : On an unrelated note, you should update the README's panda code snippet to reflect the current language state (because you did lots of changes by removing the module keyword and changed the class keyword to type).

@dzikoysk
Copy link
Member Author

dzikoysk commented Apr 9, 2021

Panda uses Type to operate on types. When you reference Java API through import/export keyword or any other generation method, the Class is just mapped to Type. It's because I didn't want to operate on standard Java classes by default due to the lack of possibility to extend such a structure.
Types are also wrapped into Reference to support some kind of lazy loading to avoid generating like thousands of types at once. Interpretation time is also problematic because of the way how JVM works, but it's yet another topic.

Yeah, README is kinda a mess (#635), I'm going to update it for beta release.

@8BitAurum
Copy link

It seems you have everything figured out!
I'll come back here soon enough to find out how Panda 0.5.0-alpha looks! All the best! ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants