-
Notifications
You must be signed in to change notification settings - Fork 136
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
FVM integration #217
FVM integration #217
Conversation
rust/src/fvm/machine.rs
Outdated
initial_pages: 1024, //FIXME | ||
max_pages: 32768, // FIXME |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stebalien any sense of the values we want to set here? Noting that WASM page size is 64KiB, so we may want to start with 16 pages (1MiB), and have no upper limit for M0? We probaly want to instrument the WASM runtime to record the pages we ended up allocating with every execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No upper limit for now. We probably also need an exception for cron.
And yeah, we need to measure it. Then 10x at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I'd actually base the max memory on the total callstack. So we'll configure some max pages here, then set max_pages to max_pages - used_pages
when instantiating a new instance.
state_root_ptr: *const u8, | ||
state_root_len: libc::size_t, | ||
blockstore_id: u64, | ||
externs_id: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think externs can be stateless if the blockstore is not folded into the externs, and kept as a separate entity (which seems to be where we're trending), but need to think more about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the very least, we'd need to be able to tell go which blockstore it should use. But if we go that way, caching will be really hard.
I'd rather go the other way and use a single ID for both externs and the blockstore. Basically, just get rid of the cgo blockstore and replace it with a cgo externs (using the same logic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've now combined them. We allow passing them as separate "handles", but under the hood we're using the same object.
rust/src/fvm/machine.rs
Outdated
pub unsafe extern "C" fn fil_fvm_machine_finish_message( | ||
machine_id: u64, | ||
// TODO: actual message | ||
) { | ||
// catch_panic_response(|| { | ||
init_log(); | ||
|
||
info!("fil_fvm_machine_flush_message: start"); | ||
|
||
let machines = FVM_MAP.lock().unwrap(); | ||
let machine = machines.get(&machine_id); | ||
match machine { | ||
Some(machine) => { | ||
todo!("execute message") | ||
} | ||
None => { | ||
todo!("invalid machine id") | ||
} | ||
} | ||
|
||
info!("fil_fvm_machine_flush_message: end"); | ||
// }) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have a "finish message" operation. What we finish is the machine, which flushes all effectively linked blocks to the blockstore, and returns the new state root CID.
@Stebalien do we expect the node to construct the receipts root, or do we want to accumulate receipts in the machine, to then return the root?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect the node to deal with that, honestly. Basically:
- The VM handles the state-tree only.
- The Node handles everything related to the blockchain.
Currently requires filecoin-project/ref-fvm#277 |
We can just pass pointers around in this case.
And correctly handle out of bounds conditions.
We don't need it, but it makes matching existing APIs simpler.
avoids some build issues
Box::leak(return_bytes); | ||
} | ||
|
||
// TODO: Do something with the backtrace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this expected to be done before being merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't planning on it.
|
||
#[no_mangle] | ||
pub unsafe extern "C" fn fil_fvm_machine_execute_message( | ||
executor: *mut libc::c_void, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this a void pointer, instead of a pointer to a concrete type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concrete type is opaque. Ideally, we'd use rust-lang/rust#43467. But c_void
is the best we can do for now.
See https://docs.rs/libc/0.2.121/libc/enum.c_void.html for how this works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, the concrete type is opaque to go.
|
||
use cid::Cid; | ||
use ffi_toolkit::{catch_panic_response, raw_ptr, rust_str_to_c_str, FCPResponseStatus}; | ||
use futures::executor::block_on; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the futures executor the one being used across the fvm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- We use the async-std executor inside the conformance tests.
- We don't use async at all inside the FVM itself.
- We need this here just to read the car file. Which we should probably just convert to sync.
We had too many parameters.
We don't support it anyways, and this simplifies the code a bit.
We've disabled the feature so this should no longer crash if we an identity hash code.
And switch to rust edition 2021, with the version-2 feature resolver.
This switches to the new bundle method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looked at this with fresh-ish eyes, and it seems good.
That way we can't get a mismatch.
fvm.go
Outdated
func (f *FVM) ApplyMessage(msgBytes []byte, chainLen uint) (*ApplyRet, error) { | ||
// NOTE: we need to call KeepAlive here (and below) because go doesn't guarantee that the | ||
// receiver will live to the end of the function. If we don't do this, go _will_ garbage | ||
// collecting the FVM, causing us to run the finalizer while we're in the middle of using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment typo
pub error_msg: *const libc::c_char, | ||
pub status_code: FCPResponseStatus, | ||
pub exit_code: u64, | ||
pub return_ptr: *const u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably confirm a leakcheck test to be sure -- this still strikes me as a leak.
pub error_msg: *const libc::c_char, | ||
pub status_code: FCPResponseStatus, | ||
pub exit_code: u64, | ||
pub return_ptr: *const u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm, I'm trying to leak-check this and getting core dumps -- can anyone else give that a go to see if it's just me?
Something like:
$ time valgrind --leak-check=full -s target/release/deps/filcrypto-0b2e0900682a616d test_sealing_aggregation_v1_1 --ignored > LOG 2>&1
Illegal instruction (core dumped)
real 0m1.282s
user 0m1.055s
sys 0m0.084s
pub error_msg: *const libc::c_char, | ||
pub status_code: FCPResponseStatus, | ||
pub exit_code: u64, | ||
pub return_ptr: *const u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to run fine otherwise :-(
$ target/release/deps/filcrypto-0b2e0900682a616d test_sealing_aggregation_v1_1 --ignored
running 1 test
test proofs::api::tests::test_sealing_aggregation_v1_1 ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 12 filtered out; finished in 12.17s
chore: build: deps: use the latest v6 & v7 actors
No description provided.